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(i) REAL PARTY IN INTEREST 

The real party in interest is FMR CORP., a corporation organized under the laws 
of Delaware. 
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(ii) RELATED APPEALS AND INTERFERENCES 

The appellant is not aware of any prior or pending appeals, judicial proceedings, 
or interferences related to the above-identified patent application. 
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(iii) STATUS OF CLAIMS 

Claims 1-3, 3-24, and 26-31 stand rejected in the application. Claim 4 and 25 
stand withdrawn. 

Claims 1-3, 3-24, 26, and 28-31 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Broadbent et al. U.S. Patent Application Publication 2001/0047326, in 
view of Fay et al. U.S. Patent Application Publication 2002/0188540, and further in view 
of Esposito U.S. Patent Application Publication 2001/0051906. Claim 27 stands rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Broadbent et al. U.S. Patent 
Application Publication 2001/0047326, in view of Fay et al. U.S. Patent Application 
Publication 2002/0188540, and in view of Esposito U.S. Patent Application Publication 
2001/0051906, and further in view of Cohen et al. U.S. Patent Application Publication 
2004/0064404. 

Claims 1-3, 3-24, 26, and 28-31 are the appealed claims. 
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(iv) STATUS OF AMENDMENTS 

None 
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(v) SUMMARY OF CLAIMED SUBJECT MATTER 

A. Claim 1 

Claim 1 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 1 describes a computerized system 
for producing a domestic relations order. [See e.g. Appellant's FIG. 2; specification pg. 
7, f [0040] lines 1-3; FIG. 3, pg. 9, f [0044] lines 1-2]. Another feature of claim 1 
describes a receiver for receiving information, alternate payee and court information, 
relating to a domestic relations order. [See e.g. Appellant's specification pg. 3, | [0009] 
lines 1-3 and 5-7]. Another feature of claim 1 describes a rules engine in communication 
with the receiver for selecting sample text passages. [See e.g. Appellant's FIG. 3; 
specification pg. 3, | [0009] lines 3-4, f [0010] lines 4-5, pg. 9, f [0046] line 3, pg. 10, 1 
[0047], lines 1-14]. Another feature of claim 1 describes a document assembler for 
automatically incorporating a first subset of the sample text passages and a second subset 
of the received information comprising the alternate payee and the court information into 
a court-compliant domestic relations order for submission to a court. [See e.g . 
Appellant's FIG 3; specification, pg. 9, Para. [0046] line 2, pg. 10-1 1, If [0048] lines 1- 
10, pg. 12, 1 [0050], lines 14-15]. 

C. Claim 3 

Claim 3 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 3 describes information associated 
with a legal representative of the participant. [See e.g. Appellant's FIG. 14; specification 
pg. 3, f [0009] lines 5-7, pg. 4, | [0012] lines 3-4, pg. 14, 1 [0058] lines 1-2] 

B. Claim 5 

Claim 5 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 5 describes information associated 
with a legal representative of the alternate payee. [See e.g. Appellant's FIG. 14; 
specification pg. 3, 1 [0009] lines 5-7, pg. 4, f [0012] lines 3-4, pg. 14, If [0058] lines 1-2] 
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C. Claim 6 

Claim 6 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 6 describes a data storage device 
for storing rules relating to a domestic relations order. [See e.g. Appellant's FIG. 3; 
specification pg. 11, Tf [0049] lines 4-6] 

D. Claim 8 

Claim 8 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 8 describes sample text passages 
related to a domestic relations order. [See e.g. Appellant's FIG. 3; specification pg. 3, ]j 
[0010] lines 2-4, 1 [001 1] lines 2-4, pg. 1 1, 1 [0048] lines 3-4]. 

E. Claim 9 

Claim 9 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 9 describes a rules engine which 
selects the first subset of sample text passages based, in least in part, on the stored rules. 
[See e.g. Appellant's FIG. 3; specification pg. 3, If [0010] lines 4-5, pg. 9, f [0046] lines 
3]. [can't find based on stored rules explicitly] 

F. Claim 10 

Claim 10 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 10 describes a rules engine which 
selects the first subset of sample text passages based, in least in part, on the received 
information. [See e.g. Appellant's FIG. 3; specification pg. 2, | [0010] lines 4-5, pg. 9, ^ 
[0046] lines 3, 1 [0011] lines 2-4]. 

G. Claim 1 1 

Claim 1 1 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 1 1 describes the document 
assembler receiving additional information previously included in a domestic relations 
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order from the data storage device. [See e.g. Appellant's FIG. 18; specification pg. 3, ^ 
[0010] lines 4-5, pg. 4, f [0012] lines 1-2, pg. 12, | [0050] lines 13-14, pg. 15, % [0062] 
lines 9-12]. 

H. Claim 13 

Claim 13 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 13 describes a method for 
producing a domestic relations order. [See e.g. Appellant's FIG. 1; specification pg. 5, ^ 
[0035] through ^ [0039], pgs. 6-7]. Another feature of claim 13 describes a method for 
providing a plurality of sample text passages relating to domestic relations orders, the 
sample text passages including embedded parameters comprising an alternate payee and 
court information. [See e.g. Appellant's FIG. 3; specification pg. 3, [0010] lines 2-4, | 
[001 1] lines 2-4, pg. 1 1, If [0048] lines 3-4]. Another feature of claim 13 includes 
requesting and receiving information for inclusion into a domestic relations order where 
the requested information including values for one or more of the embedded parameters. 
[See e.g. Appellant's FIG. 3; specification pg. 3, 1 [0009] lines 2-3, 1 [001 1] lines 4-5 
and 9-11, pg. 4, f [0012] line 1, f [0014] line 4, pg. 9, f [0045] lines 9-1 1, f [0046] lines 
4-6]. Another feature of claim 13 includes automatically assembling a court-compliant 
domestic relations order for submission to a court using a first subset of the sample text 
passages and a second subset of the requested information. [See e.g. Appellant's FIG. 3 
and FIG. 5; specification pg. 2, f [0005], lines 8-9, pg. 3, f [0010] lines 2-5, f [001 1], 
lines 2-3, t [0013] line 3, f [0014], pg. 11, f [0048], line 3, pg. 12, f [0050] lines 14-15, f 
[0051] lines 14-15]. 

I. Claim 17 

Claim 17 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 1 7 describes receiving a subset of 
the requested information form a preciously completed domestic relations order. [See 
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e.g., Appellant's FIG. 18; specification pg. 3, | [0010] lines 4-5, pg. 4, 1f [0012] lines 1-2, 
pg. 12, 1 [0050] lines 13-14, pg. 15, 1 [0062] lines 9-12]. 
J. Claim 20 

Claim 20 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 20 describes receiving a subset of 
the requested information associated with a legal representative of a participant in an 
employee benefit plan. [See e.g., Appellant's FIG. 14; specification pg. 3, f [0009] lines 
5-7, pg. 4, 1 [0012] lines 3-4, pg. 14, f [0058] lines 1-2]. 

K. Claim 22 

Claim 22 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 22 describes receiving a subset of 
the requested information associated with a legal representative of a participant in an 
employee benefit plan. [See e.g., Appellant's FIG. 14; specification pg. 3, f [0009] lines 
5-7, pg. 4, If [0012] lines 3-4, pg. 14, 1 [0058] lines 1-2]. 

L. Claim 23 

Claim 23 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 23 describes a set of rules related 
to generating a domestic relations order [See e.g., Appellant's FIG. 3; specification pg. 3, 
t [0010] lines 1-2, pg. 9, If [0046] line 3]. 

M. Claim 24 

Claim 24 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 24 describes automatically 
assembling a court-compliant domestic relations order as comprising the subset of the 
sample text passages based, at least in part, on the rules. [See e.g., Appellant's FIG. 3; 
specification pg. 3, f [0010] lines 2-4, ^ [001 1] lines 2-4, pg. 11, f [0048] lines 3-4]. 

N. Claim 26 
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Claim 26 is described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 26 describes a computerized 
system for producing a domestic relations order. [See e.g., Appellant's FIG. 2; 
specification pg. 7, f [0040] lines 1-3; FIG. 3, pg. 9, If [0044] lines 1-2]. Another feature 
of claim 26 is means for storing sample text passages for inclusion into a domestic 
relations order, the sample text passages including embedded parameters comprising an 
alternate payee and court information. [See e.g., Appellant's FIG. 3, 355, 360 and 370]. 
Another feature of claim 26 is means for receiving information about a first domestic 
relations order, the information providing values for one or more of the embedded 
parameters; [See e.g., Appellant's FIG. 3, 310, pg. 9, If [0045] lines 7-9]. Another feature 
of claim 26 is means for automatically assembling a court-compliant domestic relations 
order for submission to a court using a first subset of the stored sample text passages and 
at least a second subset of the received information. [See e.g., Appellant's FIG. 3, 330, 
pg. 9,1 [0046] lines 1-4] 

O. Claim 31 

Claim 3 1 described at least in the specification and figures at the cited locations 
which describe exemplary aspects of the claim. Claim 3 1 describes the court-compliant 
DRO is assembled according to one or more predefined document formats. [See e.g., 
Appellant's specification pg. 1 1, f [0048] lines 3-4]. 

(vi) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

A. Whether claims 1-3, 5-24, 26 and 28-31 are unpatentable under 35 U.S.C. § 103(a) 
over Broadbent et al U.S. Patent Application Publication 2001/0047326, in view of Fay et 
al. U.S. Patent Application Publication 2002/0188540, and further in view of Esposito 
U.S. Patent Application Publication 2001/0051906. The claims do not stand or fall 
together. 

a. Group I includes claims 1, 2, 7, 12-16, 18, 19, 21, 26, 28, 29. 
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b. Group II includes claims 3, 5, 20, 22. 

c. Group III includes claims 6, 8, 9, 10, 1 1, 17, 23, 24 and 31. 

B. Whether claim 27 stands rejected under 35 § U.S.C. §103(a) as being 
unpatentable over Broadbent et al U.S. Patent Application Publication 2001/0047326, in 
view of Fay et al. U.S. Patent Application Publication 2002/0188540, and in view of 
Esposito U.S. Patent Application Publication 2001/0051906, and further in view of 
Cohen et al. U.S. Patent Application Publication 2004/0064404. 
a. Group I includes claim 27. 
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(vii) ARGUMENT 

(i) Rejection under 35 U.S.C. § 103(a) over Broadbent et al. US Patent App. Pub. 
2001/0047326 Al, in view of Fay et al. US Patent App. Pub. 2002/0188540 Al, and 
further in view of Esposito US Patent App. Pub. 2001/0051906 
a. Group I - 1, 13, 26 (dependant claims 2, 7, 12, 14, 15, 16, 18, 19, 21, 27, 28, 29) 

The combination of Broadbent, Fay and/or Esposito does not teach producing a 
Domestic Relation Order as claimed 

Claims 1,13, and 26 each require receiving particular input information related to 
producing Domestic Relations Orders (DROs), specifically, alternate payee and court 
information, and producing a court compliant output of a Domestic Relations Order 
(DRO) using that input information. Broadbent and Esposito are completely silent with 
respect to DROs and Fay does not show using particular inputs to produce a DRO. The 
combination does not suggest the claimed invention nor provide any indication how 
Broadbent could be modified to arrive at the claimed invention. The Examiner is 
impermissibly relying on the hindsight of the Appellants' disclosure to provide all of the 
missing details. 

As the Examiner has stated "Broadbent does not expressly disclose a domestic 
relations order." (02/12/2007 Office Action at pg. 3) The Examiner does go on to state 
that Broadbent does disclose "a receiver for receiving information (Figure 4 A, item 401, 
pg. 9, 1 [0123], lines 3-8, Broadbent)" (Id. at pg. 3). In Broadbent, Figure 4A, item 401 
shows the input of a borrower, property and originator date via loan origination gateway 
and pg. 9, ]f [0123], lines 3-8, shows "Original inputs from a lender/loan originator come 
into the system 401 through the 'Loan Originator Gateway' (451 in FIG. 4c) or portal, 
which serves as an 'entry point' or gateway to the 'pipeline' or system for loan originator 
data and borrower data." This clearly is not "a receiver for receiving information relating 
to a domestic relations order, said information comprising an alternate payee and court 
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information" because this specific information is not included. Broadbent inputs are not 
even analogous to the inputs for producing a DRO because the required input of a loan 
originator and borrower focus on information about the lender and borrower to determine 
if a loan complies with the loan rules, not the destination of an output document that will 
be generated or its third party beneficiary. 

Further, even if, for the sake of this argument only, this were analogous, the 
combination of Fay does not result in the claimed invention. The Examiner states that 
"Fay discloses a receiver for receiving information relating to a domestic relations order, 
(pg. 2 and 8, f [0015] and [0077], lines 1-6 and 1-8;" (See e.g., Id. at pg. 3) This 
provides no direction as to modifications of Broadbent to arrive at the Appellants' 
claimed invention. Fay shows an annuity calculation system having a variable immediate 
annuity ("VIA") module 34 which may be affected by the receipt of an issued Qualified 
Domestic Relations Orders (QDROs). (See. e.g., Fay at \ [0077], lines 1-10). Fay, 
however is silent on the type of information that is received, the type of information 
needed to generate a QDRO and automated processing of that information to generate a 
QDRO. Fay does not express producing a DRO. The Examiner states that Fay expresses 
the "need to provide a defined retirement benefit which will guarantee an individual a 
minimum defined income level upon the individual's retirement" (See e.g., Id. at <\ 
[0012], lines 1-3), and that Fay satisfies that need by "providing a user with a plurality of 
periodic retirement income payments" (See e.g., Id. at f [0014], lines 3-5). These cites, 
however, do not teach or even suggest that producing a DRO is a need or a part of what is 
required to determine periodic retirement income payments. Broadbent also does not 
produce a DRO, instead a required set of tasks for a specific loan is produced (See e.g., 
Broadbent at 1 [0125], lines 5-9). Combining the Broadbent features of loan originator 
and borrower input and the Fay feature of receiving a DRO to properly calculate 
annuities does not result in "a receiver for receiving information relating to a domestic 
relations order, said information comprising an alternate payee and court information." 
Neither reference discloses alternate payee and court information. Moreover, even if 
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alternate payee and court information were disclosed by Fay, there is nothing in Fay to 
suggest that such inputs would be the needed inputs to be used by an automated system to 
generate a court compliant DRO. 

Moreover, Esposito does not provide what both Broadbent and Fay fail to suggest. 
Esposito makes no explicit mention of DROs. Further, Esposito, as the Examiner cites it, 
teaches away from the claimed invention. Specifically, the Examiner cites that Esposito 
teaches "the invention is a system that complies with reporting and disclosure 
requirements for employee benefit plans, e.g., ERISA, IRS, other federal law and state 
reporting and disclosure requirements and electronic communications regulations, as they 
relate to employee benefit plans" (See e.g., Esposito at | [0008], lines 8-13). The 
examiner has ignored that Esposito' s system complies with the rules by notifying the 
recipient via e-mail of the required plan communication. (See e.g., Id. at f [0045], lines 
1-6). This teaches away from the claimed invention because the DROs can be printed 
and submitted to the proper court, not submitted to a plan participant via e-mail as is done 
in Esposito. (See e.g., Appellant's Specification at If [0038]) 

In conclusion, Broadbent, Fay and Esposito, individually or in combination, do 
not teach modification to produce a DRO in the claimed manner apart from considering 
the Appellants' invention. 

The combination of Broadbent, Fay and/or Esposito does not teach court- 
compliance 

Claims 1,13 and 26 of the present invention each require an output of a court- 
compliant DRO. Although Broadbent suggests compliance with Federal, State, local and 
professional regulations and Esposito suggests compliance with Federal and State rules, 
Broadbent, Fay and Esposito are completely silent with respect to court-compliance. The 
combination does not suggest the claimed invention, taken as a whole, nor provide an 
indication how Broadbent could be modified to arrive at the claimed invention. The 
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Examiner is impermissibly relying on the hindsight of the Appellants' disclosure to make 
the leap from the broad statements cited to the Appellants' claimed invention. 

Broadbent does not show generating a document that is court-compliant. The 
Examiner has cited Figure 18, "loan programs that fit the criteria you entered on the 
previous pages" and page 10, f [0125], lines 5-9 in Broadbent (02/12/2007 Office Action 
at pg. 5). In Broadbent, "loan programs that fit the criteria you entered on the previous 
pg.s" in Figure 1 8 refers to "such data or information is required for originating and 
underwriting a loan, and typically includes the following: a subscribing loan originator's 
identification FIG. 7, pertinent information sufficient to identify the pending borrower 
FIG. 13, and information on the subject property FIG. 14," (See e.g., Broadbent at If 
[0132], lines 1-6). Further, | [0125], lines 5-9 shows loan data "passed by the system to 
the Compliance Engine 479 and the Compliance Engine uses these data (the loan data 
477 and the user task selections 479) to generate a required set of tasks for this specific 
loan." This is clearly not "the court information into a court-compliant domestic 
relations order for submission to a court" nor even analogous to "the court information 
into a court-compliant domestic relations order for submission to a court." Broadbent's 
Compliance Engine ensures compliance with Federal, State, local and professional 
regulations by generating a complying set of tasks for creating a mortgage (See e.g., Id. at 
| [0125], lines 5-9 and f [0026], lines 1-4). That compliance does not extend to or fall 
within complying with court rules that govern the format for generating a DRO to be 
reviewed by the court. While both the Broadbent description and the Appellants' claimed 
inventions comply with rules, compliance with rules is a broad idea which is present in 
almost all computer systems, and does not teach or suggest how to generate a DRO for 
court-compliance. 

Further, even if, for the sake of this argument only, the generation of tasks to 
ensure compliance were analogous, the combination of Fay does not result in the claimed 
invention. Though the Examiner cites Fay pg. 2 and 8, paragraphs [0015] and [0077], 
lines 1-6 and 1-8 (02/12/2007 Office Action at pg. 5), Fay is completely silent with 
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respect to generating a court-compliant document. In fact, nowhere in the description 
cited by the Examiner is there even any teaching on complying with rules. Paragraph 1 5, 
lines 1-6 discuss a retirement quoting process and paragraph 77, lines 1-8 discuss an 
annuity calculation system having a variable immediate annuity ("VIA") module 34 
which may be affected by the receipt of an issued Qualified Domestic Relations Orders 
(QDROs). As argued above, Broadbent also does not show court compliance, but instead 
complying with the Federal, State, local and professional mortgage loan regulations (See 
e.g., Broadbent at 1 [0012], lines 5-1 1 and 1 [0026], lines 1-4). Combining the Broadbent 
features of Federal, State, local and professional mortgage loan regulations compliance 
with a retirement quoting process and/or a variable immediate annuity calculation 
affected by the receipt of a DRO does not result in "the court information into a court- 
compliant domestic relations order for submission to a court." (Appellant's Claim 1) 
Neither reference discloses generating a DRO for court-compliance. Moreover, even if 
court-compliance were disclosed by Fay, there is nothing in Fay to suggest such 
compliance would be the needed compliance to be used by an automated system to 
generate a court-compliant DRO. 

Moreover, Esposito does not provide what both Broadbent and Fay fail to suggest. 
The Examiner has pointed out that on pg. 1, paragraph [0008], lines 8-13 in Esposito 
(02/12/2007 Office Action at pg. 5), Esposito teaches compliance with federal and state 
rules to avoiding "potential penalties assessed by a federal court or government agency 
for non-compliance". This cited description, however, is not the same as court- 
compliance needed to generate a DRO. Even though penalties may be issued by a federal 
court, it is not court regulations for DRO generation that is complied with in Esposito but 
federal laws, state reporting disclosure requirements and electronic communications 
regulations, as they relate to employee benefit plans. 

In conclusion, Broadbent, Fay and Esposito, individually or in combination, do 
not teach modification to produce a DRO in the claimed manner apart from considering 
Appellants' invention. 
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The combination of Broadbent, Fay and/or Esposito does not teach the use of court 
information 

Claims 1,13 and 26 of the present invention each require court information. 
Although Esposito mentions the potential for penalties assessed by a federal court for 
non-compliance Federal and State rules, Broadbent, Fay and Esposito are completely 
silent with respect to court-compliance. The combination does not suggest the claimed 
invention, taken as a whole, nor provide an indication of how Broadbent could be 
modified to arrive at the claimed invention. The Examiner is impermissibly relying on 
the hindsight of the Appellants' disclosure to make the leap from the broad statements 
cited to the Appellants' claimed invention. 

As the Examiner has stated "Broadbent in view of Fay is silent with respect to 
court information." (02/12/2007 Office Action at pg. 4) The Examiner does go on to 
state that "Esposito does disclose a system similar to the combination of Broadbent in 
view of Fay's including: court information (pg. 1, f [0008], lines 5-7 and 21-29; 
Esposito)." Id. Although the cite mentions a federal court, mere mention of a court does 
not indicate the use of that court's information. Esposito shows compliance with 
reporting and disclosure requirements for employee benefit plans to avoid potential 
penalties assessed by a federal court and does not show court information. Moreover, 
even if court information were disclosed by Esposito, there is nothing in Esposito to 
suggest such court-information would be the needed information to be used by an 
automated system to generate a court-compliant DRO. 

Cohen does not provide what Esposito fails to suggest. The Examiner Cohen as a 
basis of rejection for claim 27. The examiner cites pg. 4, paragraph [0042], lines 4-8 in 
Cohen as disclosing bankruptcy case-specific data (02/12/2007 Office Action at pg. 15 to 
pg. 16). Cohen shows the court, judge, attorney, trustee, issuer, account and a case 
number related to a bankruptcy filing. As is shown in a preferred embodiment of the 
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Appellant's Specification, paragraph [0060], the court that will issue the DRO is used to 
assure that the DRO produced is properly formatted and is not analogous to a field in a 
database holding court information extracted from a bankruptcy notice to be used for 
checking if a credit appellant has filed for bankruptcy. Additionally, there is no showing 
in Cohen regarding how to use bankruptcy case -specific data to produce a DRO and 
there is nothing to suggest that bankruptcy case-specific data is even the same data 
needed to produce a DRO. Further, there is nothing in Cohen to suggest modification to 
use the bankruptcy notice information to produce a DRO. 

In conclusion, Broadbent, Fay and Esposito, individually or in combination, do 
not teach modification to produce a DRO in the claimed manner apart from considering 
Appellants' invention. 



The combination of Broadbent, Fay and/or Esposito does not teach document 
preparation for submission to a court 

Claims 1,13 and 26 of the present invention each require document generation for 
submission of that document to a court. Although Broadbent and Esposito suggest 
providing documents, Broadbent, Fay and Esposito are completely silent with respect to 
preparing a document for court submission. The combination does not suggest the 
claimed invention, taken as a whole, nor provide and indication how Broadbent could be 
modified to arrive at the claimed invention. The Examiner is impermissibly relying on 
the hindsight of the Appellants' disclosure to make the leap from the broad statements 
cited to the Appellants' claimed invention. 

Broadbent does not show document submission to a court. Though the examiner 
cites to paragraph [0125], lines 5-9, in Broadbent, Broadbent is completely silent with 
respect to submitting a document to a court. Again, nowhere in the description cited by 
the Examiner is there even any teaching on producing a document in preparation for 
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submission to a court. Paragraph [0125], lines 5-9, discuss a compliance engine that 
ensures compliance with Federal, State, local and professional regulations by generating 
a complying set of tasks for creating a mortgage. However, Broadbent does show 
documents provided by the loan originator to the mortgage appellant (See e.g., Broadbent 
at «f [0092], lines 1-5), documents provided by the mortgage appellant to the loan 
originator (See e.g., Id. at f [0101], lines 12-14), mortgage documents provided by the 
system to the loan originator, premium broker processor and to the premium broker 
processor account executive (See e.g., Id. at f [0275], lines 16-21), and the system 
documenting "all attendant processes with compliance to applicable regulatory rule sets 
and requirements of participating workers." (See e.g., Id. at f [01 18], lines 10-14). Not 
one of these documents is produced for submission to a court. Additionally, there is 
nothing in Broadbent to suggest modification for submitting these documents to a court. 
While both Broadbent and the Appellant's claimed invention disclose providing a 
document, providing a document is a broad idea that does not suggest providing a 
document for submission to a court. 

Further, even if, for the sake of argument producing documents for delivery to the 
parties of a mortgage were analogous to producing a document for court submission the 
combination of Fay does not result in the claimed invention. Though the Examiner cites 
Fay pg. 2 and 8, paragraphs [0015] and [0077], lines 1-6 and 1-8 (02/12/2007 Office 
Action at pg. 5), Fay is completely silent with respect to court submission. In fact, 
nowhere in the description cited by the Examiner is there even any teaching on court 
submission. As stated above, paragraph 15, lines 1-6 discuss a retirement quoting process 
and paragraph 77, lines 1-8 discuss an annuity calculation system having a variable 
immediate annuity ("VIA") module 34 which may be affected by the receipt of an issued 
Qualified Domestic Relations Orders (QDROs). Broadbent also does not show court 
submission, but instead delivering documents to the parties of a mortgage. Combining 
the Broadbent features delivering documents to the parties of a mortgage with a 
retirement quoting process and/or a variable immediate annuity calculation affected by 
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the receipt of a DRO does not result in "the court information into a court-compliant 
domestic relations order for submission to a court." (Appellant's Claim 1) Neither 
reference discloses generating a DRO for court submission. Moreover, even if court 
submission were disclosed by Fay, there is nothing in Fay to suggest such court 
submission would be the needed court submission to use an automated system to generate 
a court-compliant DRO. 

Moreover, Esposito does not provide what both Broadbent and Fay fail to suggest. 
The Examiner has pointed out that on pg. 1, paragraph [0008], lines 8-13 in Esposito 
(02/12/2007 Office Action at pg. 5), Esposito teaches compliance with federal and state 
rules to avoiding "potential penalties assessed by a federal court or government agency 
for non-compliance". This cited description, again, does not describe submission to a 
court. Although penalties may be issued by a federal court, it does not follow that 
submission of an automatically produced DRO to a court is to occur. Esposito does show 
an e-mail message including a link to location a document can be viewed by one of the 
recipients (plan participant(s)) on the recipient list (See e.g., Esposito at f [0045], lines 1- 
5 and [0045], lines 1-6). Submission of an e-mail to an employee benefit plan 
participant is not the same as submission of a DRO to a court. 

In conclusion, Broadbent, Fay and Esposito, individually or in combination, do 
not teach modification to produce a DRO in the claimed manner apart from considering 
Appellants' invention, 
b. Group II - 3, 5, 20, 22 

Broadbent, Fay and/or Esposito do not teach using legal representative information 

Claims 3, 5, 20, 22 of the present invention each require use of legal 
representative information. Although Broadbent shows advisors and accountants, 
Broadbent, Fay and Esposito are completely silent with respect to legal representative 
information. The combination does not suggest the claimed invention, taken as a whole, 
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nor provide and indication how Broadbent could be modified to arrive at the claimed 
invention. The Examiner is impermissibly relying on the hindsight of the Appellants' 
disclosure to make the leap from the broad statements cited to the Appellants' claimed 
invention. 

Broadbent does not show a legal representative. The examiner cites to Paragraph 
0097, lines 1-7, in Broadbent, (02/12/2007 Office Action at pg. 6, pg. 20 and pg. 12) 
which shows non-legal representatives, "investment advisors, financial advisors, 
accountants and other professionals may be added to the Program as Loan Originators." 
(See e.g., Broadbent at f [0097], lines 1-7). In the preferred embodiment, FIG. 12 shows 
a legal representative as an attorney. Advisors, accountants and loan originators are not 
legal representatives. While both Broadbent and the Appellant's claimed invention 
disclose providing representatives, providing a representative is a broad idea that does not 
suggest providing a legal representative qualified to represent parties of a DRO. 

In conclusion, Broadbent, Fay and Esposito, individually or in combination, do 
not teach modification to produce a DRO in the claimed manner apart from considering 
Appellants' invention. 

c. Group III - 6, 8, 9, 10, 1 1, 17, 23, 24 and 31 

Broadbent, Fay and/or Esposito do not teach rules or information related to DROs 

Claims 6, 8, 9, 10, 1 1, 17, 23, 24 and 31 of the present invention all require rules 
or information related to DROs. Although Broadbent shows rules and information 
related to a mortgage and Esposito shows rules and information related to employee 
benefit plans, Broadbent, Fay and Esposito are completely silent with respect to rules or 
information related to DROs. The combination does not suggest the claimed invention, 
taken as a whole, nor provide and indication how Broadbent could be modified to arrive 
at the claimed invention. The Examiner is impermissibly relying on the hindsight of the 
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Appellants' disclosure to make the leap from the broad statements cited to the Appellants' 
claimed invention. 

Broadbent does not show rules or information related to DROs. Broadbent has a 
Compliance Engine which uses a rule-based loan compliance database to generate tasks 
required to be performed to complete a mortgage (See e.g., Broadbent at f [0051], lines 
1-6). The rules and information required to complete a mortgage (e.g., Real Estate 
Settlement Procedures Act, total cost of the loan (Id. at f [0013], lines 1-13)) are not the 
same rules or information required for a DRO (e.g., format for court submission 
(Appellant's Specification at 1 [0039]), or court information (Id. at If [0005])). 
Additionally, there is nothing in Broadbent to suggest modifying the Compliance Engine 
or information to relate to DROs. While both Broadbent and the Appellant's invention 
shows the use of rules and information, the use of rules and information is a broad idea 
which most all computers systems use and does not show the rules or information related 
to a DRO. 

Further, even if, for the sake of this argument only, the rules and information 
related to mortgages were analogous, the combination of Fay does not result in the 
claimed invention. Even though Fay shows a QDRO Fay does not use the rules or 
information related to producing a DRO, Fay simply uses the court issued QDRO as a 
variable in an annuity calculation. Combining the Broadbent features of rules and 
information related to mortgages and the Fay feature of receiving a QDRO to properly 
calculate annuities does not result in rules or information related to DROs. Neither 
reference discloses rules for the formatting of a DRO or alternate payee and court 
information. Moreover, even if rules for the formatting of a DRO, alternate payee and 
court information were disclosed by Fay, there is nothing in Fay to suggest that such rules 
and information would be the rules and information needed for an automated system to 
generate a court compliant DRO. 

Moreover, Esposito does not provide what both Broadbent and Fay fail to suggest. 
Esposito makes no explicit mention of rules or information related to DROs. The 
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Examiner cites Esposito paragraph 0068, lines 14-25. The cite is completely silent with 
respect to rules, though it shows the information of a user name, ID number, personal 
identification number, password, plan, state of user session, etc. This information is not 
the same information required, alternate payee and court information, to generate a court 
compliant DRO. Even though information is used, it is not the information required for a 
DRO. 

In conclusion, Broadbent, Fay and Esposito, individually or in combination, do 
not teach modification to produce a DRO in the claimed manner apart from considering 
Appellants' invention. 
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SUMMARY CONCLUSION OF ALL ARGUMENTS 

The Examiner has not met the initial burden of establishing a prima facie case for 
obviousness. As described in the MPEP § 2143: 

To establish a prima facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference 
or to combine reference teachings. Second, there must be a reasonable expectation of 
success. Finally, the prior art reference (or references when combined) must teach or 
suggest all the claim limitations. 

The teaching or suggestion to make the claimed combination and the reasonable 
expectation of success must both be found in the prior art, not in applicant's disclosure. 
In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). 

As argued herein, there is no motivation and further, the combinations made by 

the Examiner do not teach or suggest all the claim limitations. The invention must be 

considered as a whole and the Examiner cannot simply chose references using the claim 

elements as a guide. 

Further, as stated many times, the Examiner has simply ignored claim limitations, 
abstracting some claim limitations to a general concept to enable the Examiner's 
obviousness rejections. It is clear, however, that the type of data and/or the use of 
specific data can be patentable and must be considered. For example, just because 
automating processes is known, this does not mean that automating the production of a 
court-compliant DRO for court submission is obvious. Similarly, DRO's are received by 
many agencies, for many purposes, e.g. used as a variable in an annuity calculation as in 
Fay. However, this does not mean that any mention of a DRO makes it obvious to 
produce a court-compliant DRO. While Broadbent does show producing documents, 
producing documents is an ancillary function of Broadbent which is used to show ensure 
compliance required tasks for executing a mortgage and does not contemplate the system 
claimed by the Appellant. While the Examiner keeps arguing the inherent capability of 
the Broadbent system to be capable of automatically producing a DRO as claimed by the 
Appellant and to be capable of performing the functions as claimed by the appellant, 
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there is no question that the Broadbent system would need to be reconfigured to do so. 
Besides the Appellant's own specification, there is very little, if any guidance on the 
record on how that would be done. The Examiner seems to be relying mostly on the 
knowledge of one skilled in the art. However, there is nothing indicating that one skilled 
in the art would have the knowledge, without reading the Appellant's specification, to 
make the modifications necessary to produce a court-compliant DRO for court 
submission. 

In view of the foregoing authorities, remarks, and the inability of the references, 
alone or in combination, to anticipate, teach, or suggest the subject matter as a whole of 
the invention disclosed and claimed in this application, the decision of the Examiner 
rejecting claims 1-3, 3-24, and 26-31 should be reversed. 




Respectfully submitted, 



Proskauer Rose LLP 



One International Place 
Boston, MA 02110 



Telephone: 617-526-9600 
Facsimile: 617-526-9899 
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(viii) CLAIMS APPENDIX 



1 . A computerized system for producing a domestic relations order comprising: 

a receiver for receiving information relating to a domestic relations order, said 
information comprising an alternate payee and court information; 

a rules engine in communication with the receiver for selecting sample text 

passages; and 

a document assembler for automatically incorporating a first subset of the sample 
text passages and a second subset of the received information comprising the alternate payee and 
the court information into a court-compliant domestic relations order for submission to a court. 

2. The system of a claim 1 wherein the received information comprises information 
associated with a participant in an employee benefit plan. 

3. The system of a claim 2 wherein the received information comprises information 
associated with a legal representative of the participant. 

5. The system of claim 3 wherein the received information comprises information 
associated with a legal representative of the alternate payee. 

6. The system of claim 1 further including a data storage device for storing rules relating to 
a domestic relations order. 

7. The system of claim 6 wherein the data storage device further stores sample text 
passages. 

8. The system of claim 7 wherein the sample text passages relate to a domestic relations 
order. 
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9. The system of claim 6 wherein the rules engine further selects the first subset of the 
sample text passages based, at least in part, on the stored rules. 

10. The system of claim 1 wherein the rules engine further selects the first subset of the 
sample passages based, at least in part, on the received information. 

1 1 . The system of claim 6 wherein the document assembler receives additional information 
from the data storage device, the additional information having been previously included in a 
domestic relations order. 

12. The system of claim 1 further comprising an administrative module for maintaining the 
rules engine. 

13. A computerized method for producing a domestic relations order, comprising: 

providing a plurality of sample text passages relating to domestic relations orders, 
the sample text passages including embedded parameters comprising an alternate payee and 
court information; 

requesting information for inclusion into a domestic relations order, the requested 
information including values for one or more of the embedded parameters; 
receiving the requested information; and 

automatically assembling a court-compliant domestic relations order for 
submission to a court using a first subset of the sample text passages and a second subset of the 
requested information. 

14. The method of claim 13 further comprising receiving the requested information over an 
electronic communications network. 
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15. The method of claim 14 wherein the electronic communications network is one of a local 
area network, a wide area network, a telephone network, an intranet, the Internet, or any 
combination thereof. 

1 6. The method of claim 1 3 further comprising receiving the requested information through 
an online questionnaire. 

17. The method of claim 13 further comprising receiving at least a subset of the requested 
information from a previously completed domestic relations order. 

1 8. The method of claim 1 3 further comprising receiving at least a subset of the requested 
information associated with a participant in an employee benefit plan. 

1 9. The method of claim 1 8 wherein the employee benefits plan comprises a defined 
contribution plan, a defined benefit plan, or both. 

20. The method of claim 1 3 further comprising receiving subset of the requested information 
associated with a legal representative of a participant in an employee benefit plan. 

2 1 . The method of claim 1 3 further comprising receiving a subset of the requested 
information from an alternate payee of an employee benefit plan. 

22. The method of claim 21 further comprising receiving at least a subset of the requested 
information associated with a legal representative of the alternate payee of an employee benefit 
plan. 

23. The method of claim 22 further comprising providing a set of rules relating to generating 
a domestic relations order. 
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24. The method of claim 23 wherein automatically assembling the court-compliant domestic 
relations order comprises determining the subset of the sample text passages based, at least in 
part, on the rules. 

26. A computerized system for producing a domestic relations order, comprising: 

means for storing sample text passages for inclusion into a domestic relations order, the 
sample text passages including embedded parameters comprising an alternate payee, and court 
information; 

means for receiving information about a first domestic relations order, the information 
providing values for one or more of the embedded parameters; and 

means for automatically assembling a court-compliant domestic relations order for 
submission to a court using a first subset of the stored sample text passages and at least a second 
subset of the received information. 

27. The system of claim 1 wherein said court information comprises a case number. 

28. The method of claim 16 further comprising determining one or more questions for the 
online questionnaire based on a rules engine and a subset of the requested information. 

29. The method of claim 1 3 wherein assembling comprises using a document template. 

30. The method of claim 29 wherein automatically assembling the court-compliant domestic 
relations order comprises using a subset of the requested information as input for one or more 
parameter fields of the document template. 

3 1 . The system of claim 1 wherein the court-compliant domestic relations order is assembled 
according to one or more predefined document formats. 
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(ix) EVIDENCE APPENDIX 

Broadbent et al U.S. Patent Application Publication 2001/0047326, in view of Fay et al. U.S. 
Patent Application Publication 2002/0188540, and view of Esposito U.S. Patent Application 
Publication 2001/0051906, and further in view of Cohen et al. U.S. Patent Application 
Publication 2004/0064404. 

A. Broadbent et al U.S. Patent Application Publication 2001/0047326 
Citation entered in the record by examiner in Notice of References Cited 

contained in July 6, 2006 Office Action and the February 12, 2007 Final Rejection. 

B. Fay et al. U.S. Patent Application Publication 2002/0 1 88540 
Citation entered in the record by examiner in Notice of References Cited 

contained in July 6, 2006 Office Action and the February 12, 2007 Final Rejection. . 

C. Esposito U.S. Patent Application Publication 2001/0051906 
Citation entered in the record by examiner in Notice of References Cited 

contained in the February 12, 2007 Final Rejection. 

D. Cohen et al. U.S. Patent Application Publication 2004/0064404 
Citation entered in the record by examiner in Notice of References Cited 

contained in the February 12, 2007 Final Rejection. 

E. Final Rejection 

Final rejection entered by the examiner February 12, 2007. 
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(x) RELATED PROCEEDINGS APPENDIX 
None 
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Publication Classification 
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(57) ABSTRACT 

The present invention provides a solution to the needs 
described above through a system and processe to be used in 
the mortgage industry for combining an Loan Application 
System with an automated Compliance Engine used for 
generating and monitoring a set of required procedures 
involved in moving and tracking a mortgage loan through 
one or more of the steps of 'originate', 'approve', 'close', 
'fund', and 'ship'. The automated compliance engine itself 
is a system and method for automatically generating a set of 
required tasks for use in managing the mortgage loan 
process, including tasks required by applicably federal or 
state law. The system of the present invention automatically 
couples the regulatory compliance information engine and a 
task management system required to process loans and 
provides methods for integrating the Automate Compliance 
Engine technology with any third party's loan processing 
software. 
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Have you declared bankruptcy in the last 7 years? 
Oyes Cno 

if so what kind of bankruptcy was filed? 

if yes, what yaar and month was the bankwptcy filed? 

Year : [ j Month : lJon_@ 

was bankruptcy duo to financial mismanagement? 
Oyes Cno 

Have you had a home foreclosed or given a deed in lieu in the last 7 years? 
Oyes Ono 
if yes, what year? 
Year : I I Month : | Jem |jH 

Do you have any outstanding liens or judgements? 



How many times have you been past due on any mortgage in the last 24 months? 
How many times have you been past due on any other debt in the last 24 months? 

m 

How many times have you been past due on any mortgage In the last 12 months? 
EI 

How many times have you been past due on any other debt in the last 12 months? 
EI 

How long do you expect to be in the home? 
Citizenship Status 

b_ w 
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TSSi b^iw * Instructions: The following are the loan programs that tit the 
«lt »* option*.' criteria you entered on the previous pages. Please click on the loan 

program title that best meets Your needs. 



- t5 Year Fixed Rate. Expanded Credit. Full Dccnmenlatinn 

8.625% -0.750 10.137% $137.00 S1 ,500.00 
Sub-Prime. 15 Year FixBd Rata. Full Documanlatinn 



$13j500.00 

11.300% 0.G00 12721% $156.00 $1,500.00 J13.500.00 
15 Year Fixed Rate. 103% ITV 

14.000% 0.000 15.218% $190.00 $1,500.00 $13,500.00 
3% DWP, 30 Year Fixed, fate 

8.875% 1.E75 10.498% $113.00 $1,500.00 $13,500.00 
3% Down. 30 Year Fixed Rata 

8.875% 1.875 10.496% $113.00 $1,500.00 $13,500.00 

30 Year Fix ed Rate, Expanded Credit. Full Documentatio n 

8.625% -0.750 3.902% $111.00 $1,500.00 $13,500.00 

8.750% -0.125 10.113% $112.00 $1,500.00 $13500.00 
30 Year Fixed Rata 103% I TV 

9.000% -0.500 9.627% $120.00 $1,500.00 $13,500.00 
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Loan Program Selected: 

15 Year Fixed Rate, Expanded Credit, Full Documentation 



Loan Amount J13.SOO.00 
Down Payment: $1,500.00 
Hale: B.625% 



Principal 4 Interest: 5134.00 
Taxes 8. Insurance 517.00 
Mortgage Ins: $3.00 
Total Monthly Payment: $154.25 



Origination Fee (HUD #301) 
Points Paid/Discount 
Appraisal Fes (HUD #303) 
Underwriting Fee (HUD #312) 
Administration Fee (HUD #315) 
Settlement or Closing Fee (HUD #1101) 
Title Insurance (HUD #1108) 
Recording/Filing Fees (HUD #1201) 
Survey (HUD #1301) 

Per diem interest (HUD #901) 15 days @ $3.19 
Total: 



$135.00 
(11013) 



$595.00 

$250.00 
$36.00 

$250.00 
$47.05 
$2,157.60 



A. 
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Frank Schmuk 

Current Street Address |l234AnyStrast j~ 

Current City | AnyTcwne ~ j~ 

Current Slate, Zip |ak"1I , ,12345 I " 

°*"/R<>nt EOwn ORenr 

Length oftae at this address Ye3rs ^Z}, Months E~> 
If less than 2 years complete the following information 





®Ovm ORent 




Years I"" - 1 


Months 1 1 


1 1 



Previous address 2 (include 
city, state, zip) 

°<™IR«* <?Own ORent 

Length of time at this address Ye8rs r— ] „ f- 
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Subject property zip 
# 0elete Number of units 

HZZ1- 

Occupancy Type 
I Owner Occupied 

How long do you expect to be in the borne? 
Property Type 

[Single Fami^Detached |« 
Building Status 
[grating ||f 

If acondo or PUD • whst are estimated HOA fees/month? 




Figure 25 
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loan guarantee? 




(1) What type of property did you own? 




Figure 28 
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INPUT GATEWAY 3400 




FIG. 33 
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Figure 34 
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TASK MAINTENANCE & STATUS REPORTING GATEWAY 



TASK DATA 
TASK RESPONSE DATA 
LOAN STATUS REQUEST 
LOAN STATUS RESPONSE 



BUSINESS 

CLIENT 
(INTERNET) 
XML - 



INDIVIDUAL 
(WEBSITE) 
HTML 



CONVERT 
OUTGOING MESSAGE 

FROM FORTE 
CONDUCTOR API TO 
DESIRED PROTOCOL & 
FORMAT 



/ WORKFLOW \ 
I PROGRESS J 




WIRELESS 
PDA 
WML 


— * 


^4209 


RECOGNIZE INPUT 
PROTOCOL & 
FORMAT 




^-4211 


CONVERT INPUT TO 
FORTE CONDUCTOR 
API 




r 4212 


AUTHENTICATE 
INPUTTER 




S. 4214 



FIG. 35 
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TRANSACTION SERVICE PROVIDER GATEWAY 4400 




TRANSLATE 
RESPONSE INTO 
WORKFLOW ENGINE 
FORMAT 



TRANSLATE MESSAGE 
FROM WORKFLOW 
FORMAT TO FORMAT 
& PROTOCOL FOR 
SERVICE PROVIDER 



RELEASE THE CIRCUIT 
CONNECTION 



4407 



ESTABLISH 
COMMUNICATIONS 
LINK TO SERVICE 
PROVIDER 



RESPONSE ENTERED 
BY SERVICE 
PROVIDER 



SEND MESSAGE AND 
WAIT FOR RESPONSE 




NOTIFY SYSTEM 
ADMIN 



FIG. 36 
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Figure 37 
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l^OStep 4: Borrower Updates and Loan Processing 
35% of loan orgination fee 

Task 

• Review and explain undetwriting decision with borrower 0> Loan Originator 

• Review and explain other closing conditions to the O Real Estate Broker 

boiro ** r , , . L „ „ n Mortgage Processing 

o Review and explain the Good Faith Estimate with 
borrower 

o Review and explain the Truth in Lending statement 

with borrower 
o Review and explain other federal and state 

disclosures with borrower 

• Get borrower's signature on documents 

• Collect the mandatory conditions from the borrower 

o Collect the income information (paystubs, W2 and 

tax records as required) 
o Collect the bank statements from the borrower 
o Collect the Insurance Binder information 

• Forward all conditions to processing 

• Review and explain the results of the Title Report 

• Review and explain the results of the Appraisal 

• Review and explain the results of the Flood Certification 

• Provide regular status updates to the borrower 

• Order the Flood Certification 

• Order the Survey (as required) 

09 Step 5: Closing 
15% of loan orgination fee 
Task 

• Review and authorize the Clear to Close document from 
processing 

• Lock the interest rate for the loan 

• Coordinate closing with borrower and title company. 

• Attend closing 



<?' Loan Originator 
O Real Estate Broker 
O Mortgage Processing Center 



^ Go Back 

Figure 40 



Go Forward * 
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Change to View By Borrower 
H« Task Description 
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INTERFACE SYSTEM FOR A MORTGAGE LOAN 
ORIGINATOR COMPLIANCE ENGINE 

RELATED APPLICATIONS 
[0001] This application is a continuation-in-part to non- 
provisional co-pending application Ser. No. 09/645,217 
Filed Aug. 24, 2000, titled "Method and Apparatus for a 
Mortgage Loan Originator compliance Engine." This appli- 
cation is filed in accordance with 37 CFR § 1.53 (b)(2) and 
is also related to the following co-pending non-provisional 
utility applications: 

[0002] Ser. No. 09/645,799 filed Aug. 24, 2000, titled 
"Method and Apparatus for a Mortgage Loan Man- 
agement System." 

[0003] Ser. No. 09/645,775 Filed Aug. 24, 2000, 
titled "Method and Apparatus for a Mortgage Loan 
Origination Gateway"; 

[0004] Ser. No. 09/645,796 Filed Aug. 24, 2000, 
titled "Method and Apparatus for Verification of a 
Qualified Mortgage Loan Originator"; 

[0005] Ser. No. 09/645,800 Filed Aug. 24, 2000, 
tilled "Method and Apparatus for a Mortgage I-oan 
Task Flow Process"; 

[0006] Ser. No. 09/645,798 Filed Aug. 24, 2000, 
titled "Method and Apparatus for a Mortgage Loan 
Process Interaction Gateway"; 

[0007] Ser. No. 09/645,801 Filed Aug. 24, 2000, 
titled "Method and Apparatus for a Mortgage Loan 
Transaction Service Provider Gateway"; and 

[0008] Ser. No. filed Feb. 13, 2001, titled 

"Method and Apparatus for an Advanced Speech 
Recognition Portal for a Mortgage Loan Manage- 

COPYRIGHT NOTICE 
[0009] A portion of this patent document contains material 
which is subject to copyright protection. The copyright 
owner has no objection to the facsimile reproduction by 
anyone of the patent document or the patent disclosure, as it 
appears in the Patent and Trademark Office patent file or 
records, but otherwise reserves all copyright rights whatso- 



TECHNICAL FIELD 
[0010] The present invention relates to the general field of 
computers, telecommunications, and computer and Internet 
related systems. More specifically the invention relates to 
systems and processes to be used in the mortgage industry 
for combining a customer Loan Application System with an 
automated Compliance Engine used for generating and 
monitoring a set of required procedures involved in moving 
and tracking a mortgage loan through one or more of the 
steps of 'originate', 'approve', 'close', 'fund', and 'ship'. 

BACKGROUND 
[0011] Bank and other lending companies in the mortgage 
loan industry have developed automated loan application 
processing systems to make the loan application process 
more efficient and more centrally controlled. Such systems 



are typically programmed to generate some of the tasks 
associated with a mortgage loan application such as request- 
ing an appraisal, evaluating the loan contract and application 
data, authorizing a loan, tracking the closing activities and 
completing the financial disposition of the loan. Such sys- 
tems generally contain no regulatory oversight or control of 
the tasks performed. Such oversight and control is assumed. 

[0012] There is a need for an automated system for 
managing the processing of mortgage loan applications, 
wherein the identification of the loan originator, his/her 
location and the location of the property which is the subject 
of the loan, determine the Federal and State mortgage loan 
laws and regulations as well as the professional guidelines 
which govern the loan transaction, and wherein the auto- 
mated system uses the specific loan regulations to determine 
the tasks required to complete a loan transaction, including 
tasks required by applicably federal or state law, provide the 
set of required tasks to lenders and other interested parties, 
record the completion of the set of tasks, and if requested by 
a lender, to use the set of tasks internally to drive the flow 
of the automated mortgage loan process to completion. 
Furthermore there is a need for such a regulatory compliance 
system which can easily be coupled to existing loan appli- 
cation processing systems. 

[0013] The Federal laws and regulations in question are 
basically those outlined in the Real Estate Settlement Pro- 
cedures Act (RESPA) and the Federal Housing and Urban 
Development's (HUD's) implementing Regulation X. The 
State regulations in question are those State specific regu- 
lations and implementing instructions that serve a similar 
purpose, relating to Lender payments to Mortgage Brokers 
and other settlement service providers. RESPA is the federal 
law implemented by IIUD's Regulation X, to protect home 
buyers from excess costs and confusion when securing a 
home mortgage loan. Among other federal laws, the Truth in 
Lending Act ("TILA") and the Equal Credit Opportunity Act 
("ECOA") impact the mortgage loan process. Under the 
TILA, certain credit related disclosures are required to be 
made to the borrower prior to the consummation nf a 
mortgage loan transaction, so that the borrower understands 
the total cost of the loan. 

[0014] The ECOA and its implementing regulation, 
Regulation B, were enacted and promulgated to require that 
lenders make credit equally available to all creditworthy 
borrowers without regard to race, color, religion, national 
origin, sex, marital status, age, receipt of public assistance or 
the fact that the borrower in good faith exercised any right 
under the Federal Cousumer Credit Protection Act. In addi- 
tion to the prohibition against discrimination, the ECOA and 
Regulation B also contain, among others, requirements 
regarding ihe provision of appraisal reports, evaluation of 
applications, spousal signatures, and the provision of 
adverse action notices. 

[0015] Regarding state laws, most jurisdictions have 
enacted licensing statutes that may require real estate sales 
professionals, builders, financial institutions/lenders and 
mortgage brokers to obtain a license and satisfy various 
other financial, educational and operational requirements. 
Most jurisdictions also have enacted laws that impose, 
among others, requirements regarding the types of fees that 
may be charged to a consumer in connection with a mort- 
gage loan transaction and the persons entitled to receive 
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such fees, as well as certain jurisdiction-specific disclosures 
that must be provided to the consumer. 

[0016] There is a need for a system to facilitate the 
application of all of these laws and regulations ("regula- 
tions") in an efficient and systematic manner during the 
course of a mortgage loan transaction by using the telecom- 
munications and computing facilities available to the market 
today. 

[0017] While some state laws are more restrictive, RESPA 
allows a licensed real estate professional to receive com- 
pensation for originating a mortgage loan only if that real 
estate professional provides goods or facilities or performs 
services that are necessary for the origination of the loan and 
that are separate and distinct from any services the real estate 
professional provides incident to the sale of the property that 
secures the mortgage loan. Moreover the mortgage loan 
process is labor intensive, error prone and time consuming 
for all parties concerned, making it diiEcult for a real estate 
professional to track the services he or she provided to 
satisfy RESPA and state requirements to justify receiving 
compensation. 

[0018] The demand for fairness and equity, as well as an 
increasingly competitive lending environment, was the rea- 
son why RESPA was passed and now requires a greater level 
of sophistication on the part of the lending community. 
Furthermore as indicated above, increasing oversight on the 
part of governments and regulatory agencies have required 
increased levels of sophistication in the traditional borrower- 
lender relationship. While these oversight demands are 
generally considered to be a benefit to the borrower-lender 
relationship, it is, nonetheless a burden to all parties, and 
significant increases in both time and cost are accrued to the 
process. As well, protective regulations added by the lending 
community under whose umbrella the industry operates, 
further protract the process of 'doing business'. These 
regulations and 'rules' governing the mortgage process 
permit those in the loan origination role to receive a fee for 
services rendered when the applicable rules are followed, as 
well as penalties and loss of fees for non-compliance. For 
example, RESPA has criminal penalties wherein a violator 
can go to jail for up to a year. 

[0019] In the past, attempts have been made to automate 
some parts of the mortgage loan process. For example, U.S. 
Pat. No. 5,995,947 issued Nov. 30. 1999 to IMX Mortgage 
Exchange titled "Interactive Mortgage and loan information 
and real-time trading system" provides a system and method 
for trading loans wherein a transaction server maintains a 
database of pending loan applications and their statuses, and 
wherein each party to the loan (broker, lender) can search 
and modify the database consistent with their role in the 
transaction. However this system focuses on only one facet 
of the loan process itself. Other parts of the loan process are 
addressed in U.S. Pat. No. 5,966,700 issued Oct. 12, 1999 to 
Federal Home T/ian Rank of Chicago, titled "Management 
System for Risk Sharing of Mortgage Pools" is a system 
wherein a mortgage originator (bank, savings & loan, etc.) 
and a funding institution (Federal Home Loan Bank, etc.) 
agree to assume certain risks for the mortgage by entering 
into a credit agreement having an overall credit enhance- 
ment value, and wherein the system calculates and records 
the allocation of mortgage interest and credit risk between 
them. This system functions after a mortgage has been 



issued which is outside of applicants' present system. 
Another recently issued patent related to mortgage loans is 
U.S. Pat. No. 5,991,745 issued Nov. 23, 1999 to Fannie Mae, 
titled "Reverse Mortgage Loan Calculation System and 
Process", which is a payment calculation system related to 
loans that the borrower is generally not required to repay 
until the security properly is sold. Still another is U.S. Pat. 
No. 5,940,812 issued Aug. 17, 1999 to LoanMarket 
Resources, LLC titled "Apparatus & Method for Automati- 
cally Matching a Best Available Loan to a Potential Bor- 
rower via Global Telecommunications Network" teaches a 
system for matching loan requests (and related credit data) 
to lenders (with related eligibility criteria) in order to 
facilitate such loans whether they be for automobile pur- 
chases or whatever. Similarly, other U.S. Patents teach 
methods for real time loan approval (U.S. Pat. No. 5,870, 
721), methods for Lender direct credit evaluation and loan 
processing (U.S. Pat. Nos. 6,029,149; 5,930,776; and 5,611, 
052); and methods for keeping track of loans, loan histories, 
leases and pertinent data related thereto (U.S. Pat. No: 
4,774,664). 

[0020] Inherent in most property transactions, especially 
those involving a mortgage, are other elements which, as 
suggested before, serve to protect the interests of all con- 
cerned parties, but which unnecessarily protract the under- 
writing process. These generally include at least the follow- 
ing: a processing procedure and fee to originate the loan 
application, a title search to discover any encumbrances on 
the property such as liens, overdue taxes, etc., a credit check 
on the borrower of record to determine the credit-worthiness 
of the individual, a verification of employment which speaks 
to the individual's ability to repay the loan, a property 
survey, where such is dictated by local laws, an appraisal to 
determine if the property value secures the lender's invest- 
ment, application for various insurances such as flood, 
earthquake, or other insurance as local law and custom 
requires, the loan application itself, and other such applica- 
tions, searches, and discoveries, as local laws dictate. In 
addition to the aforementioned, an income to debt ratio is 
established to help select the most appropriate loan pro- 
gram^) consistent with the lender's policy and the borrow- 
er's requirements. As indicated above, many lenders have 
implemented automated Loan application processing sys- 
tems which attempt to keep track of some or all of these 

[0021] Of equal importance in the process is the distribu- 
tion of service fees and commissions associated with real 
estate mortgage transactions. The timeliness and accuracy of 
transactions can adversely affect the payment of various 
agents or workers involved in the process. Furthermore, 
because of the almost casual connection between the parties 
to the transaction, coupled with heretofore rigid definitions 
of each worker's responsibility, creative solutions to the 
aforementioned problems were not forthcoming, and little 
could be done to remedy these problems. Personal interven- 
tion on the part of agents or other workers could help, but 
weren't part of the scope of the transaction, were unreliable, 
and were differentially applied, often in consideration of 
such elements as the wealth or prestige of the borrower, the 
value of the property, personal friendships, or other less 
tangible factors. 

[0022] Many of the agents or workers participating in the 
transaction bear a limited portion of the responsibility for the 
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transaction. Employment verification, title searches, and the 
like, are often of fixed duration and required effort with 
mortgages falling within a broad value range. As such, these 
workers enjoy a steady, regulated income flow. It falls 
however, to the real estate agent to invest time on an 
open-ended basis to accomplish a sale. In this instance, the 
commission is often fixed by industry convention or statute, 
and the Real estate sales professional typically doesn't enjoy 
the benefit of serving as both listing and buying agent, which 
might net a full commission. More typically, the agent must 
make a 50 /so split with another agent or agency. Adding 
injury to this significant commission reduction is the typical 
requirement that the remaining commission balance be split, 
usually <%>, with the Real estate sales professional's parent 
agency. It is common for a Real estate sales professional, 
having invested many hours over a period or weeks or 
months, to realize a modest 1-2% of the selling price of the 
property. Given this scenario, it is expected that a Real estate 
sales professional will focus on opportunities which will 
bear fruit faster, and leave the longer-term prospects alone, 
even though they have a similar reward and are of equal 
value in the eyes of the respective buyers and sellers. 
[0023] The current state of the art simply does not provide 
a means whereby the real estate sales professional, or any 
other agent or worker, may participate in the other portions 
of the monetary flow, beyond that which is historically 
common to their respective industries. 
[0024] While there are a number of developing systems, as 
mentioned above, for automated lender .selection and loan 
tracking, it is clear that a need exists for an automated 
system based upon a database of federal, state and local rules 
and regulations, which can be used to identify, tor a given 
loan transaction, the set of tasks required to process and 
complete the loan transaction, including tasks required by 
applicably federal or state law, and to track the set of tasks 
during the process itself to reasonably assure that compli- 
ance with these rules and regulations can be reported, or 
alternatively, that compliance task completion may be traced 
to the entity reporting completion. There is a further need to 
automatically attach the regulatory compliance information 
with a task management system required to process loans 
and to provide methods for integrating the Compliance 
Engine technology with any third party loan application 
processing software. 

SUMMARY OF THE INVENTION 

[0025] The present invention provides a solution to the 
needs described above through a system and process to bo 
used in the mortgage industry for combining a lender's Loan 
Application System with an automated Compliance Engine 
used for generating and monitoring a set of required proce- 
dures involved in moving and tracking a mortgage loan 
through one or more of the steps of 'originate', 'approve', 
'close', 'fund', and 'ship'. The automated compliance 
engine itself is a system and method for automatically 
generating a set of required tasks for use in managing the 
mortgage loan process, including tasks required by applica- 
bly federal or state law. The system of the present invention 
automatically couples the regulatory compliance informa- 
tion engine and a task management system required to 
process loans and provides methods for integrating the 
Automate Compliance Engine technology with any third 
party's loan processing software. 



[0026] 'lhe automated system of the present invention uses 
the Federal, State, local and professional regulations and 
requirements and implementing instructions to generate a 
plurality of tasks which can be used to control and drive the 
process of handling a mortgage loan application to comple- 
tion and settlement in accordance with these regulations . 
Mortgage loan requestors may specify that the system will 
generate the plurality of required tasks, including tasks 
required by applicably federal or state law, provide the 
plurality of required tasks to the requester for his execution, 
including tasks required by applicably federal or state law, 
and monitor the completion of all required tasks so as to 
provide a completion certificate to the requestor. Alterna- 
tively, mortgage loan requestors may specify that the auto- 
mated system will generate the plurality of required tasks, 
including tasks required by applicably federal or state law, 
will manage and control the execution of the required tasks, 
and monitor the completion of all required tasks so as to 
provide a completion certificate to the requestor. 

[0027] The invention allows loan originators to enter loan 
applications and comprises a platform to allow other entities 
to underwrite the loan (that is, this invention is not a loan 
approval system, but can use any lender's loan approval 
system) but which provides the means to control and drive 
the mortgage transaction to closing by means of a compli- 
ance system which contains a rules engine built around the 
required Federal and State regulations and which tracks and 
records every step in the process to provide a record of 
completion for Federal and State regulators. The invention 
was designed to provide mechanisms for use to assure that 
loan originators meet and exceed federal, state, local and 
professional laws governing the relations between real estate 
sales and mortgage lending activities. 

[0028] A computer implemented method is disclosed for 
facilitating processing of a mortgage loan application 
wherein the system receives a request to process a mortgage 
loan from a third party loan processing system; generates a 
plurality of tasks, the tasks comprising actions required to 
process the mortgage loan, and including tasks required by 
applicable federal and/or state law; and distributes one or 
more of the required tasks to the third party loan processing 
system for execution of the tasks. The" method further 
provides an act of monitoring the completion of the plurality 
of tasks whereby a report of completion of all required tasks 
can be generated. 

[0029] An apparatus is disclosed for automated processing 
of mortgage loans which has a compliance engine with 
communications devices for receiving a request to process a 
mortgage loan from a client loan processing system; the 
compliance engine having logic devices programmed to 
generate a plurality of tasks required to process the loan, 
wherein the tasks are made up of actions which are required 
for a specific mortgage loan by various legal rules and 
regulations; and wherein the compliance engine has logic 
devices programmed to distribute the plurality of tasks to the 
client loan processing system. 

[0030] Also disclosed is a server node in a network which 
is responsive to a request to process a loan from a third party 
loan processing system by generating a plurality of tasks 
which are required to process the requested loan, including 
tasks required by applicably federal or state law, and for 
distributing the plurality of tasks to persons who are quali- 
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lied to perform the tasks. Also disclosed are mechanisms in 
the server node for monitoring the completion of the plu- 
rality of tasks related to a given loan and for generating 
reports and completion certificates associated with the 
actions related to the given loan. 

[0031] Also, a computer program stored on a computer 
readable medium or carrier wave is disclosed having com- 
puter code mechanisms for receiving a loan request from a 
client loan processing system; for generating a plurality of 
tasks required to process the loan, including tasks required 
by applicably federal or state law, and distributing the 
plurality of tasks to the client loan processing system for 
execution. Additional code mechanisms are disclosed which 
monitor the completion of the plurality of tasks and when all 
tasks are completed can issue various reports and comple- 
tion certificates. 

[0032] Still other embodiments of the present invention 
will become apparent to those skilled in the art from the 
following detailed description, wherein is shown and 
described only the embodiments of the invention by way of 
illustration of the best modes contemplated for carrying out 
the invention. As will be realized, the invention is capable of 
modification in various obvious aspects, all without depart- 
ing from the spirit and scope of the present invention. 
Accordingly, the drawings and detailed description are to be 
regarded as illustrative in nature and not restrictive. 

DESCRIPTION OF THE DRAWINGS 

[0033] The features and advantages of the system and 
method of the present invention will be apparent from the 
following description in which: 

[0034] FIG. 1 illustrates a typical configuration of Internet 
connected systems representative of the preferred embodi- 
ment of the present invention. 

[0035] FIG. 2 illustrates a typical general purpose com- 
puter system of the type representative of the preferred 
embodiment. 

[0036] FIG. 3 illustrates the business model which 
encompasses the present invention. 
[0037] FIGS. 4A & 4B illustrate a functional flow chart of 
a preferred embodiment of the system. 
[0038] FIG. 4C illustrates a configuration of an embodi- 
ment of the system which contains the invention. 

[0039] FIG. 4D illustrates exemplary functions of the 
Compliance Engine. 

[0040] FIG. 5 illustrates a configuration of an alternative 
embodiment of the system which contains the invention. 
[0041] FIG. 6 is a flow chart depicting the process Map 
and Workflow Definition for a New Loan. 
[0042] FIGS. 7-30 illustrate exemplary screenshots for the 
system embodying the present invention. 
[0043] FIG. 31 illustrates an exemplary Internet configu- 
ration showing the hardware and software systems used in 
an embodiment at this time. 

[0044] FIG. 32 illustrates another exemplary Internet con- 
figuration showing the hardware and software systems used 
in an embodiment at this time. 



[0045] FIG. 33 illustrates an exemplary embodiment of 
the Input gateway module. 

[0046] FIG. 34 illustrates an exemplary relationship of 
various system elements with the GHR sub-system. 
[0047] FIG. 35 illustrates an exemplary embodiment of 
the "task maintenance & status reporting" gateway. 
[0048] FIG. 36 illustrates a preferred embodiment of the 
"transaction service provider" gateway. 
[0049] FIGS. 37-41 depict additional screen shots of the 
system embodying the invention, showing an exemplary set 
of tasks required to complete a loan. 

DETAILED DESCRIPTION 
[0050] 'JTie present invention provides a solution to the 
needs described above through a system and process to be 
used in the mortgage industry for combining a client Loan 
Application System with an automated Compliance Engine 
used for generating and monitoring a set of required proce- 
dures involved in moving and tracking a mortgage loan 
through one or more of the steps of 'originate', 'approve', 
'close', 'fund', and 'ship'. The automated compliance 
engine itself is a system and method for automatically 
generating a set of required tasks for use in managing the 
mortgage loan process, including tasks required by applica- 
bly federal or state law. The system of the present invention 
automatically couples the regulatory compliance informa- 
tion engine and a task management system required to 
process loans and provides methods for integrating the 
Automate Compliance Engine technology with any third 
party's loan processing software. 

[0051] The heart of various embodiments of the present 
invention is a module designated an Automated Compliance 
Engine (the "Compliance Engine") which is designed to 
maintain and use a rules-based loan compliance database to 
generate the set of tasks required to be performed to com- 
plete and close a specific mortgage loan transaction. This 
Compliance Engine is described in more detail below. 
Similarly, the method of the interface between the compli- 
ance engine and a client loan application processing system 
is described in more detail below. However, we now 
describe a general overview of a preferred embodiment of 
the invention. 

[0052] (1) General Overview 

[0053] All mortgage loans will be originated through the 
applicants (OnePipeLine.com) website. In the future, web- 
sites other than Applicant's will be used to originate loans 
that will interface with the compliance engine. The technol- 
ogy used as part of the system currently is able to interface 
with many other industry standard software programs to 
make the exchange and flow of data easy and accurate. 
[0054] The system is predominantly web-enabled, which 
extends its use to all industry professionals connected to the 
Internet. The system contains the Compliance Engine that 
applies Federal, State, Local, and profession based filters to 
each loan application and each Loan Originator to create a 
combined task list that defines a custom workflow process 
for every transaction originated through the System and 
Program, which forms the basis for monitoring the steps and 
procedures required for a specific loan transaction in order 
to provide a completion report for the specific mortgage 
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loan. The rules applied to each new mortgage loan applica- 
tion will determine who is permitted or required to perform 
which services in the loan origination process under the 
Program and who will receive fair market compensation for 
services actually performed. The System then creates a 
record of the actual workflow. The list, as a composite of 
compensation or origination tasks and required tasks, is 
represented as a 'task list', and may optionally be presented 
to a subscriber client through an API. 

[0055] In a preferred embodiment of the invention, the 
automatic compliance engine's processes and workflow are 
integrated with the client's loan origination system (LOS) in 
a manner which results in a compliant loan. The resulting 
system, which is the product of the client's LOS and the 
compliance engine and its interface, provides comprehen- 
sive workflow, forms and disclosures, closing requirements, 
tracking, a compliance report, a compliance certificate of 
guarantee. The net result is a product which is a lender 
branded business to business system, thereby opening a new 
channel with which to compensate third party originators. 
[0056] In a preferred embodiment, the main features of the 
union of a client LOS and the compliance engine arc: 

[0057] 1) a XML based programming interface that 
allows for specific loan and compliance data to be 
shared between the compliance engine and the cli- 
ent's consumer direct web-based LOS. The XML 
messages are delivered back and forth between the 
compliance engine system and the client LOS using 
HTTPS POST events. 

[0058] 2) a scries of branded web pages — hosted by 
applicants— that control and manage the delivery of 
the consultative and prequalification compliance 

[0059] The development of this XML based interfaced 
system usually requires a business process review of the 
client's LOS with recommendations of changes and 
enhancements necessary to move them to a compliant third 
party loan origination system. These changes encompass 
technology, web page content, and business processes that 
need to be performed, typically by the client's employees. 
[0060] (2) Detailed Description 

[0061] In an embodiment of the combined client/lender 
LOS and applicants compliance engine ("the System"), the 
Borrower and Loan Originator work together throughout the 
loan origination process. Once a Borrower decides to work 
with a Loan Originator on the System, the System will have 
the Borrower and Loan Originator answer typical financial 
and property questions concerning the Borrower. The 
answers to these questions will allow the System to pre- 
qualify the Borrower for a loan and offer appropriate loan 
program options to the Borrower, and authenticate the loan 
Originator in the system. For example, when an agent 
originator is ready to begin the loan process, he/she must be 
authenticated through applicant's credentialing database. 
The primary mechanism for this to occur is through an XML 
API developed by applicant and implemented in the client 
LOS. 

[0062] It is necessary for the agent to review the process 
with their client, pre-qualify their client as to the amount of 
home and loan amount they can afford, and to disclose 



certain information to their clients via business disclosure 
forms. When this part of the transaction is completed, a loan 
instance is created using the compliance engine and the 
appropriate tasks are marked as complete. Additionally, the 
compliance engine system generates an ACS ID# which is a 
unique transaction identifier, which becomes part of the 
Loan Record which will be created using the Client's LOS. 
This identifier can either be manually entered by the agent 
or programmatically delivered from the applicants system to 
the lender system using the designed XML API. The client 
will use this unique identifier to track and report back to 
applicants compliance engine system on the progress of the 
loan through the rest of the process. 

[0063] At this point in the process, the agent is directed 
back into the client's consumer direct LOS (which has beeu 
reviewed and modified for third party loan origination). 
Once the System makes this information available to the 
Borrower and Loan Originator, the Borrower will be able to 
choose to make a formal mortgage loan application on-line 
through the Loan Originator. 

[0064] After the agent has worked through the Client's 
loan application system (at the point the application is 
submitted for processing) The compliance engine system 
needs to receive a subset of the collected loan data in order 
to update the compliance record in the compliance engine 
system. The compliance engine will use that data to update 
the task list and recheck the compliance of the loan appli- 
cation. The data coming back to Applicants will be delivered 
either programmatically using the XML API or through a 
manual web page interface that the client's loan processors 
will use. 

[0065] (Loan Status Updates): At five specific times dur- 
ing the processing and underwriting process, the compliance 
engine system needs to be made aware of changes in the loan 
status. The compliance engine system notifies the third party 
originator so they can keep the borrower up to date and the 
loan progress. The client's LOS can notify the compliance 
engine system of these status changes using the XML API or 
the client can alter it's business process to have the loan 
processor come to the compliance engine system web site, 
and manually make the changes to the loan status. 

[0066] Closing & Certification Data Transfer: When the 
loan is ready to go to closing, the client needs to receive 
from the compliance engine system key information per- 
taining to closing instructions that must be followed to 
ensure the HUD1 document is prepared correctly. 

[0067] During the processing of the loan, certain data may 
have changed which would impact the compliance of the 
loan. For this reason, the client must reconfirm with the 
compliance engine system the loan details. 

[0068] The client can transmit the loan data to the com- 
pliance engine system via the XML API or via a web based 
manual interface (similar to what is described above). Upon 
receipt of this data, the compliance engine system evaluates 
it and produces a Compliance Report and loan specific 
Closing Instructions (related to compensating the third party 
loan originator). The compliance engine system delivers the 
report and instruction back to the Client using the same 
mechanism that was used to request this information (i.e. 
XML API or web page). 
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[0069] After closing, there are two things that need to be 
delivered to the compliance engine system provider (appli- 

[0070] A check to compensate applicants and the 
third party originator, and 

[0071] A copy of the entire loan file for archiving 
purposes. 

[0072] Once these two items are received by applicants, 
the compliance engine system, produces a 'Compliance 
Guarantee', which is printed out and placed into the loan file. 
[0073] An exemplary sequence of events is as follows: 

[0074] The Loan Originator consults with the bor- 
rower about the property and loan products generally 
available, 

[0075] After entering the required data, including a 
self-declared credit profile, the application is pro- 
grammatically compared to available products, typi- 
cally using a service and program of the type pro- 
vided by GHR's PremierPricer™ software, or 
client's own system. 

[0076] If a list of suitable products is returned by a 
GHR-like system, the Loan Originator assists the Borrower 
in selecting the preferred loan product, The Application is 
then re-submitted to the GHR-like product selection system 
and the credit rating of the Borrower is programmatically 
obtained, 

[0077] With the 'official 1 credit rating available, the GHR- 
like system returns a list of one or more loan products, 
[0078] If the desired loan product is on the list, then the 
application process proceeds to underwriting, 
[0079] If the desired product is not available, but there are 
other loan products, then the Loan Originator and the 
Borrower will select and apply for another suitable loan 
product, 

[0080] If no loan products are available, then the system 
returns an appropriate notification, and the loan application 
is forwarded to the lender, with the initial desired loan 
product, for human review, adjustment, and probable selec- 
tion of a suitable loan product for underwriting. 
[0081] Making either selection will notify the System of 
the Borrower's intent to proceed with the mortgage loan 
origination process and will initiate the rules evaluation 
process, coincident with underwriting of the loan, as 
described in the next paragraph. 

[0082] The System's Compliance Engine will apply a set 
of rules appropriate to each mortgage loan transaction, 
including property and borrower profile, originator's pro- 
fessional guidelines, state and federal regulations and other 
relevant rules. The final filtered task list will then apply to 
each mortgage loan transaction in an attempt to assure that 
the mortgage loan is originated in accordance with appli- 
cable federal and state laws. This will include, making sure 
that qualified Loan Originators, Independent Contractors 
and Local Loan Processors are permitted to perform services 
associated with the loan origination process and that all 
services required to be performed in order for the Loan 
Originator, Independent Contractor and/or Local Loan Pro- 



cessor to receive compensation in connection with the 
mortgage loan transaction are actually performed. 
[0083] Based on the mortgage loan origination process 
requirements defined by the Compliance Engine, the Loan 
Originator will make decisions about each of the service 
providers (e.g., inspection companies, surveyors, appraisers, 
title companies, etc.) the Loan Originator wishes to have 
involved in the mortgage loan transaction. Any qualified 
service provider will be able to be selected by the Loan 
Originator and entered into the System at this point. Some 
nationwide service providers may, in the future, have a direct 
online ordering system available inside the System. Others 
may still require the typing in of the name and contact 
information. Applicants expect that it will be most common 
for Borrowers to select local service providers with whom 
they are familiar. 

[0084] After the Borrower selects the service providers, 
the Loan Processor will confirm to the system which ser- 
vices have been provided by the Loan Originator. As 
described in more detail below, the services actually per- 
formed by the Loan Originator, Independent Contractor 
and/or Ixical Ix>an Processors will serve as the basis for the 
fees earned as fair market compensation for performing 
settlement services in connection with the mortgage loan 
origination process under the Program. 
[0085] After each of the above steps are completed, the 
System will automatically create a workflow process based 
on the applicable rules and appropriate tasks will be even- 
tually assigned to each of the service providers for the 
mortgage loan transaction. In a preferred embodiment, the 
mortgage loan data and applicable tasks will be passed to a 
workflow generation system, either implemented as an inte- 
gral part of the system of the invention, or as a service 
provided by a remote application service provider (ASP), 
which will generate an automated workflow process which 
can notify each service provider of his task(s) and allowing 
each service provider to interact in completing needed tasks. 
All task assignments will be distributed by the System and 
tracked. At this point, many people will be working on the 
loan simultaneously though the System. For example, the 
Loan Originator may be obtaining financial information 
from the Borrower, the Independent Contractor may be 
ordering an appraisal, the Ixical Txian Processor may be 
verifying Borrower information, and various service provid- 
ers may be performing services and adding information to 
the mortgage loan file through the System. Hard copy data 
will be input by either Applicant's staff, an Independent 
Contractor (to the extent permitted under state law) or the 
Local Loan Processor, and added to the physical mortgage 
loan file. Work notices and status communications may be 
generated automatically by the System to keep the process 
moving and to ensure that all appropriate parties perform 
their assigned tasks in the proper order to meet all rules 
requirements applicable to the mortgage loan transaction. 
[0086] c. Products Available 

[0087] Borrowers may obtain a loan using the facilities of 
the lender organization, in which mode the system of the 
invention merely determines which tasks are required and 
tracks the completion of the required tasks. By obtaining a 
loan through the Program, Borrowers will be given access to 
a wide variety of first lien, fixed and variable rate, closed- 
end mortgage products (both purchase money and refinanc- 
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ings) at competitive rates and pricing, and in a timely and 
efficient manner. For example, as noted above, Applicants 
will make available to the Borrower, loan products and 
interest rates that are available from its participating lenders. 
Applicant's System and Program also will make available 
and support secondary lien, fixed and variable rate, closed- 
end loan products and interest rales available from its 
participating lenders. In the future, Applicants may give 
Borrowers access to first and second lien, fixed and variable 
rate, open-end mortgage products through the Program. 
Applicant's Program and System will not make available or 
support mortgage loans that constitute "Iligh Cost" or 
Section 32 mortgage loans, which are covered bv Section 32 
of Regulation Z, 12 C.F.R § 226.3 
[0088] d. Funding Source 

[0089] In a preferred embodiment, Applicants will not 
fund any mortgage loans, and no mortgage loans will be 
closed in Applicant's name. Applicants will be acting exclu- 
sively in the capacity as mortgage broker. All mortgage 
loans will be funded by, and closed in the name of, a 
participating lender. In an alternative embodiment, Appli- 
cants could fund certain mortgage loans and close loans in 
their name in those jurisdictions where qualified to do so. 
[0090] e. Disclosures and Form Documents 
[0091] In a preferred embodiment, the System will pro- 
duce applicable Borrower disclosures (on a state specific 
basis) required under applicable law to be provided to the 
Borrower in connection with the mortgage loan origination 
process under the Program. The Loan Originator will be 
required to provide the disclosures to Borrowers at the 
appropriate times. Moreover, the Loan Originators will be 
required to provide the Borrower with a disclosure that 
informs the Borrower that the Loan Originator will receive 
compensation for services actually performed by the Loan 
Originator in connection with the mortgage loan transaction. 
This disclosure also will inform the Borrower that the Loan 
Originator is an exclusive part-time W-2 employee of Appli- 
cants, and that the Borrower is free to use another mortgage 
broker or lender other than Applicants. 
[0092] The System also will allow a lender to elect to use 
a standard set of mortgage loan documents, which can be 
printed off of the System, in connection with a mortgage 
loan originated through Applicant's Program, or the Lender 
may use its own forms. The forms available off of the 
System will be provided to Applicants by a third-party 
document vendor. 

[0093] f. Mortgage Loan Fees 

[0094] Fees will generally include, among other permis- 
sible fees: (1) origination fee payable to the lender and 
passed through to the Loan Originator based on services 
performed; (2) underwriting fee payable to the lender and 
passed through to Local Loan Processor; (3) impound 
waiver fee payable to the lender and passed through to 
secondary market investor (only on loans without escrow 
accounts); (4) processing fee payable to the lender and 
passed through to Local Loan Processor; (5) document 
preparation fee payable to the lender and passed through to 
third-party vendor; (6) tax related service fee payable to the 
lender and passed through to third-party vendor; and (7) 
attorney fee payable to lender and passed through to closing 
attorney. Applicants will charge a lender a membership fee 



to participate in Applicant's Program and a flat fee for each 
Completion Certificate issued to the lender. 
[0095] g. Loan Originators 

[0096] In a preferred embodiment, mortgage loans will he 
originated through the System and Program by licensed real 
estate sales professionals, such as real estate agents/sales- 
persons and, in limited cases, real estate brokers. The 
individual real estate agents and individual real estate bro- 
kers (i.e., brokers that are not corporations or similar busi- 
ness entities) will enter into an employment agreement with 
Applicants, and become part-time W-2 employees of Appli- 
cants. The employment agreements will expressly require 
the Loan Originator to originate mortgage loans exclusively 
for Applicants, and prohibit the Loan Originators from 
receiving compensation for performing loan origination 
services for another mortgage lender or mortgage broker. 
[0097] In the future, other non-traditional originators, such 
as investment advisors, financial advisors, accountants and 
other professionals may be added to the Program as Loan 
Originators, in each case to the extent permitted by appli- 
cable law. Loan Originators may also have an affiliation with 
a mortgage lender, which defines the selection of loan 
products the Loan Originator may offer. 
[0098] i. Local Loan Processors 

[0099] In a preferred embodiment, wherein the loan is 
being processed through the system of the invention, loan 
processing functions which would trigger mortgage broker 
or similar licensing requirements under applicable state law 
will be delegated to properly licensed Local Loan Processors 
who will receive compensation intended to be fair compen- 
sation for services actually rendered by them. The Local 
Loan Processors will be either mortgage brokers and mort- 
gage bankers. 

[0100] j. Sendees Performed 

[0101] As noted above, in a preferred embodiment, a Loan 
Originator will initiate the mortgage loan process with a 
borrower using Applicant's System, I "he services that a Loan 
Originator will have to perform, in all cases, in order to be 
fully compensated include the following: (1) obtaining the 
applicant's signature on disclosures, (2) obtaining the appli- 
cant's signature on the credit authorization, (3) prc-qualify- 
ing applicants, (4) assisting applicants in selecting loan 
products, (5) taking the loan application or obtaining loan 
application information, (6) reviewing the credit decision 
with the applicant, (7) explaining the good faith estimate and 
other disclosures to the applicant, (8) collecting documen- 
tation from the applicant that is needed in connection with 
processing and underwriting the loans, (9) updating the 
applicant and responding to applicant inquiries, (10) locking 
the interest rale, and (11) scheduling and attending the 
closing. 

[0102] If a Ixian Originator docs not perform all required 
services, the services will be performed by Applicant's staff, 
Lender's staff, an Independent Contractor (to the extent 
permitted under applicable state law) or by a Local Loan 
Processor, and the compensation received by the Loan 
Originator will be reduced accordingly. 

[0103] By way of additional background, the basic of the 
rules and regulations which form the heart of the present 
invention are now described in more detail. 
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[0104] RESPA Compliance 

[0105] The following is a brief summary of RESPA and its 
implementing regulation, Regulation X, and their require- 
ments. It is not intended to be comprehensive. For example, 
RESPA and Regulation X may not apply in all situations, 
and their application is not discussed below. Users should 
consult RESPA Regulation X and independent legal counsel 
for complete explanation of RESPA Regulation X and their 
requirements. 

[0106] The Real Estate Settlement Procedures Act 
("RESPA") is a federal statute that was enacted by Congress 
in 1974. A federal regulation implementing RESPA ("Regu- 
lation X") also has been promulgated by the United States 
Department of Housing and Urban Development ("HUD"). 
HUD is the federal agency charged with administering and 
enforcing RESPA, Regulation X and their requirements. 
[0107] RESPA was enacted to provide Borrowers with 
greater and more timely information on the nature and costs 
of the home buyiug/settlement process, and to protect Bor- 
rowers from unnecessarily high settlement charges caused 
by certain practices believed to be abusive. Among other 
requirements, RESPA and Regulation X prohibit the pay- 
ment or receipt of "any fee, kickback or thing of value" (i.e., 
a referral fee) in exchange for the referral of settlement 
service business. Settlement service business includes, 
among other services, loan origination services such as 
taking applications, obtaining income verifications and com- 
municating with a borrower or lender. 
[0108] RESPA and Regulation X permit a lender to make 
reasonable payments to its agents and contractors for ser- 
vices actually performed in the origination, processing or 
funding of a loan. Based on interpretations of this provision 
in RESPA and Regulation X, real estate sales professionals 
and others may, in certain circumstances, provide loan 
origination services and receive fair market compensation 
for the services they actually perform. 

[0109] The preferred embodiment of the invention in 
Applicant's program and system are designed around this 
provision. Applicant's loan originators arc required to per- 
form certain settlement services in connection with loans 
originated by Applicants, and the compensation received by 
these loan originators and regional loan processors is 
intended to be fair market compensation for the services 
they actually perform. 

[0110] Other Federal and State Compliance 

[0111] The following is a brief summary of other federal 
and state statutes, regulations and laws that impact Appli- 
cant's system and program, and a user's performance of 
services under this system and program. It is not intended to 
be comprehensive. Users should consult the statutes, regu- 
lations and laws, and independent legal counsel, for a 
complete explanation of other applicable federal and state 
statutes, regulations and laws. 

[0112] Among other federal laws, the Truth in Lending 
Act ("TILA") and the Equal Credit Opportunity Act 
("ECOA") impact Applicant's program and system, and the 
user's performance of services under applicant's system and 
program. The TILA and its implementing regulation, Regu- 
lation Z, were enacted and promulgated to assure meaning- 
ful disclosure of credit terms so that the Borrower will be 



able to compare more readily the various terms available to 
the Borrower. Under the TILA, certain disclosures are 
required to be made to the Borrower prior to the consum- 
mation of a mortgage loan transaction. 

[0113] The ECOA, and its implementing regulation, 
Regulation B, were enacted and promulgated to require that 
lenders engaged in the extension of credit make that credit 
equally available to all creditworthy Borrowers without 
regard to race, color, religion, national origin, sex, marital 
status, age, receipt of public assistance or the fact that the 
Borrower in good faith exercised any right under the Federal 
Consumer Credit Protection Act. In addition to the prohibi- 
tion against discrimination, the ECOA and Regulation B 
also contain, among others, requirements regarding the 
provision of appraisal reports, evaluation of applications, 
spousal signatures, and the provision of adverse action 

[0114] Regarding state laws, most jurisdictions have 
enacted licensing statutes that may require real estate sales 
professionals, builders, financial institutions/lenders and 
mortgage brokers to obtain a license and satisfy various 
other financial, educational and operational requirements. 
Most jurisdictions also have enacted laws that impose, 
among others, requirements regarding the types of fees that 
may be charged to a Borrower in connection with a mort- 
gage loan transaction and the persons entitled to receive 
such fees, as well as certain jurisdiction-specific disclosures 
that must be provided to the Borrower. 

OPERATING ENVIRONMENT 
[0115] The environment in which the present invention is 
used encompasses the use of general purpose computers as 
client or input machines for use by loan originators, lenders 
and other parties interested in the mortgage loan process. 
Such client or input machines may be coupled to the Internet 
(sometimes referred to as the "Web") through telecommu- 
nications channels which may include wireless devices and 
systems as well. 

[0116] Some of the elements of a typical Internet network 
configuration are shown in FIG. 1, wherein a number of 
client machines 105 possibly in a branch office of an Real 
Estate Service, or financial institution, lender, etc., are 
shown connected to a Gateway/hub/tunnel-server/etc. 106 
which is itself connected to the internet 107 via some 
internet service provider (ISP) connection 108. Also shown 
are other possible clients 101, 103 possibly used by other 
loan originators, or interested parties, similarly connected to 
the internet 107 via an ISP connection 104, with these units 
communicating to possibly a home office via an ISP con- 
nection 109 to a gateway/tunnel-server 110 which is con- 
nected 111 to various enterprise application servers 112, 113, 

114 which could be connected through another hub/router 

115 to various local clients 116, 117, 118. Any of these 
servers 112, 113, 114 could function as a server of the 
present invention, as more fully described below. Any user 
situated at any of these client machines would normally have 
to be an authorized user of the system as described more 
fully below. 

[0117] An embodiment of the Mortgage Loan Manage- 
ment System of the present invention can operate on a 
general purpose computer unit which typically includes 
generally the elements shown in FIG. 2. The general pur- 
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pose system 201 includes a motherboard 203 having thereon 
an input/output ("I/O") section 205, one or more central 
processing units ("CPU") 207, and a memory section 209 
which may or may not have a flash memory card 211 related 
to it. The I/O section 205 is connected to a keyboard 226, 
other similar general purpose computer units 225, 215, a 
disk storage unit 223 and a CD-ROM drive unit 217. The 
CD-ROM drive unit 217 can read a CD-ROM medium 219 
which typically contains programs 221 and other data. Logic 
circuits or other components of these programmed comput- 
ers will perform series of specifically identified operations 
dictated by computer programs as described more fully 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0118] In consideration of it's major aspects, the present 
invention is a system and methodology, comprising a 'con- 
tainer' concept, wherein the mechanics of real estate trans- 
actions beginning with loan origination and proceeding 
serially and in some instances in parallel through the closing, 
funding and disbursement and reporting of funds may be 
accomplished. The system also controls the timing of Lbe 
process and the time allocated to the completion of each loan 
occurrence. When the time allocated to a process expires, the 
task is transferred as required by the rule base. The system, 
constituting the present invention, is designed to program- 
matically manage and document all attendant processes with 
compliance to applicable regulatory rule sets and require- 
ments of participating workers. In a preferred embodiment, 
data exists within the executing programs as 'objects', the 
meaning of which as commonly understood by those skilled 
in the art of 'object-oriented programming'. In a preferred 
embodiment, the software programs comprising a portion of 
the present invention are also object-oriented. An integrated 
relational database management system is utilized to main- 
tain persistent data and to permit and facilitate queries and 
reports against the persistent data. While the embodiment of 
the present invention embraces certain elements of a 'closed 
loop', or self-contained decision-making process, it's 
strength lies in the ability to orchestrate the workers or 
agents participating in the lending transaction with respect to 
responsibilities and financial compensation. 

[0119] The system of the invention encompasses a means 
whereby the object-oriented 'instances' or discrete occur- 
rences of data, may be stored and retrieved from the rela- 
tional database management system. In the preferred 
embodiment, such storage and retrieval is accompanied by 
programmatic conversion of said data instances to 'formats', 
or preferred representations upon which the required pro- 
grants) may act. Such data storage occurrences and the 
accompanying manipulations of said data follow preferred 
programmatic documentation procedures such as sequen- 
tially 'nested' descriptors. An example of a sequentially 
'nested' descriptor would be, 'borrowcr.occupation', where 
the nested descriptors are separated by a '.' or 'dot', and in 
such manner are understood to mean, 'the identified bor- 
rower's occupation'. Such 'dot' notation will hereafter be 
used to describe the higher level of programmatic function- 
ality when such explanation is necessary. Those skilled in 
the art will understand JAVA™ programming, Object ori- 
ented Programming, and the use of automated "Agents" to 
perform programmed tasks whenever activated to do so, 



HTfP, XML and other communications protocols as 
described in more detail below. 

[0120] An exemplary way to articulate the concept and 
embodiment of the present invention is the idea of a 'con- 
tainer', which brings together the loan originator, the subject 
real property attributes, and the lender, as well as means to 
validate transaction profitability and bundle said transac- 
tions for sale to lenders. Or in an alternative view, as a means 
for generating the required compliance tasks for a specific 
loan transaction, provide the tasks to a lender and monitor 
the completion of all required tasks by the lender's service 
providers. The present invention provides decision points 
wherein the loan originator makes selections from menu(s) 
generated by the compliance engine acting upon the original 
information supplied by the originator. The selection process 
introduces the refined data into an integrated 'workflow' 
process wherein rule-based engines and other workers or 
agents act toward a common goal of closing, funding, 
shipping, and collecting transaction fees on a loan. 

[0121] Referring to FIG. 3 there is illustrated, in sche- 
matic form, a preferred embodiment of the present inven- 
tion. The business model is comprised of several functional 
elements, including at the highest level, embodiments which 
effect loan origination 301, closing, processing 303, funding 
305, and shipping 307, with transfer of funds. In concert, 
these elements may be referred to as the 'pipeline' or system 
which embodies the whole of the several elements compris- 
ing the present invention. 

[0122] As indicated above, the present invention is a 
method and apparatus for automating the process of gener- 
ating a set of tasks required for controlling, and regulating 
a mortgage loan application, underwriting the loan, and 
tracking the tasks through the closing process, wherein the 
tasks comply with all known Federal, State and local 
requirements for the specific loan. Elements of an alternative 
embodiment include loan origination, authenticating the 
loan originator, underwriting the loan, closing, processing, 
funding, and shipping, with transfer of funds, within the 
regulatory legal framework of funding and reporting, 
required for these processes. In a preferred embodiment, 
which is described in detail below, some or most of these 
functions may be performed by the lender or application 
service providers (ASPs) with the system of the invention 
providing the set of required tasks generated by a Compli- 
ance Engine and simply monitoring the completion of those 

[0123] Referring now to FIGS. 4A, 4B, 4C and 4D, the 
principal elements of a preferred embodiment of the present 
invention are illustrated in more functional detail. Original 
inputs from a lender/loan originator come into the system 
401 through the 'Loan Origination Gateway' (451 in FIG. 
4C) or portal, which serves as an 'entry point' or gateway to 
the 'pipeline' or system for loan originator data and bor- 
rower data. The loan originator data 403 is used as input data 
to an authentication module (453 in FIG. 4C) to verify the 
lender/loan originator's ID and password. Those skilled in 
these arts will recognize that this authentication process for 
the client/user may include digital signature authentication 
as well as other types of cryptographic verification and 
authentication of users. If the lender/loan originator's ID and 
or password do not authenticate, a message is sent back to 
the originator indicating that fact and the system exits. If the 
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loan originator is found to be qualified, the loan originator 
data and borrower data are passed to the Compliance Engine 
405 (476 in FIG. 4D) for later use. The borrower-supplied 
credit data is then passed to a Loan Origination & Program 
Matching module 407 (456 in FIG. 4C). The Iran Origi- 
nation & Program Matching module returns a list of loan 
products for which the borrower is qualified 409. In a 
preferred embodiment, this function is provided by a Pre- 
mierPricer™ program supplied by GHR Systems™ Inc. The 
PremierPricer™ Component is described in more detail at 
the GHR Systems web site, which can be found at www.gh- 
rsystems.com, which description is hereby incorporated 
fully herein by reference. Additional detail on the interface 
to this PremierPricer™ Component is provided below. In an 
alternative embodiment, the Loan Origination & Program 
Matching module is one which is supplied by applicants as 
an integral part of the pipeline system, wherein up-to-the- 
minute product and pricing information is provided when 
the module is supplied with basic transaction parameters 
(i.e., LTV, loan amount, property location, property type, 
etc.). 

[0124] Continuing with reference to FIG. 4A, borrower 
then selects a loan from the list of loan products for which 
the borrower is qualified and submits a loan application 411. 
In a preferred embodiment, the system, recognizing the loan 
application selection, submits a credit report request to a 
credit bureau 413 and passes this data to the GHR Systems 
PremierPricer™ Component 413. A list of loan products for 
which the borrower is qualified are returned to the lender & 
borrower 415. If the borrower is not qualified for any loans, 
419 the loan request is referred to a loan officer and the 
system exits 429. If the borrower is qualified, he selects one 
of the listed loans (his original selection may or may not be 
on this list) 421, 423. Referring now to FIG. 4B the lender 
uses this data to process the loan and inputs loan approval 
data to the system 431. 

[0125] The loan data is passed to the Compliance Engine 
431 (477 in FIG. 4D). As part of this set of input data the 
user/lender selects optional tasks for this loan and inputs his 
selections along with data indicative of his fee arrangement 
with the borrower 432. Referring now to FIG. 4D, this data 
is passed by the system to the Compliance Engine 479 and 
the Compliance Engine uses these data (the loan data 477 
and the user task selections 479) to generate a required set 
of tasks for this specific loan (433 in FIG. 4B). This required 
set of tasks is generated 478 by selecting the tasks from the 
task file 480 which are specifically required by the particular 
loan (i.e. loan type, location, value, etc.) and the contexts 
481 (i.e. the combinations of circumstances where the tasks 
apply). The resultant set of tasks for the specific loan 483 is 
separately recorded 482 in a file which can be modified as 
new tasks may be added or deleted, and as task completions 
are identified 485. 

[0126] In a preferred embodiment, the system can supply 
this required task list in its entirety to the lender if the lender 
wishes to manage the task completions himself through his 
own automated systems (see 441, 443 in FIG. 4B). In this 
case, the system would merely monitor task completion data 
445 (see also 485, 486, 487 and 488 in FIG. 4D) and if 
required, issue a Completion Certificate 447 when the tasks 
are completed and the loan process closed. If the user/lender 
wants Applicants to handle the loan, the Compliance Engine 
can transfer the set of tasks for this loan to an internal Loan 



Processing & Workflow engine 437. 'lluis internal Loan 
Processing & Workflow engine (Forte Conductor™, Frame- 
work Lendware™, etc) (see also 462, 463, 464, 466 and 467 
in FIG. 4C) will automatically transmit specific tasks to 
specific workers who have been previously identified as 
responsible for those kind of tasks 438, will supply task 
completion data to the Compliance Engine 440 when tasks 
are completed. The Compliance Engine will supply the 
completion data to the system so as to generate worker 
compensation and loan completion reports (see 468 in FIG. 
4C), and Completion Certificates 442. The final process 
module in the system, the Banking & Loan Management 
process (469 in FIG. 4C), adds the loan, if it was provided 
by Applicants, and its related financial parameters to the 
inventory of loans managed by applicants. In a preferred 
embodiment, this Banking & Loan Management process 
469 includes a secondary banking engine which manages the 
packaging and placing of loans with secondary financial 
institutions so as to optimize the financial returns on the 
loans handled by applicants. This process would be managed 
by Lendware™ via an on-site installation or by a Frame- 
work™ application service provider (ASP) or equivalent 
implementation. In an alternative embodiment, this second- 
ary banking engine which manages the packaging and 
placing ofloans with secondary financial institutions so as to 
optimize the financial returns on the loans handled by 
applicants would be a package developed internally by 
applicants. 

[0127] A depiction of an alternative embodiment of the 
present invention is shown in FIG. 5 which describes the 
elements shown in FIGS. 4A, 4B and 4C in a different 
depiction. Each of these features is described in more detail 
below. The 'Loan Origination Gateway '501 or portal, serves 
as an 'entry point' or gateway to the 'pipeline' or system. 
The loan originator enters data for both himself and for the 
borrower. This data is passed to the Authentication module 
503 which uses these data as inputs to the Compliance 
Engine 520. The Compliance Engine 520 uses these data 
from its associated worker's description 521 and legal 
context 523 files to determine whether the loan originator 
can originate this loan for this property. If so, the Authen- 
tication module 503"authenticates" the transaction and 
passes the information to the Loan Origination System 505 
for analysis of correspondent pricing and for underwriter 
approval. As indicated above, this function could be per- 
formed by the system or through the interface to an equiva- 
lent service such as the PremierePricer™ product supplied 
by GHR Systems™ Inc. Then the loan originator is asked to 
indicate which tasks he will do (of the optional tasks 
available) 519. These optional task and fee data along with 
the original Loan Originator data and borrower data and 
underwriter data are then passed to the Compliance Engine 
520 wherein the mandatory task identified based on the 
legal requirements for this loan originator and this location 
of the property, and the selected optional tasks are combined 
by the Compliance Engine 520 into a required set of tasks 
for this loan and passed as inputs to the Loan Fulfillment 
System 545. The Loan Fulfillment System 545 assembles 
the inputs and task requirements for input to the Mortgage 
Workflow Engine 553 which automatically manages the task 
execution by various responsible parties. In the process of 
managing the execution of the required tasks the Mortgage 
Workflow Engine 553 automatically communicates with 
parties having an interest in this loan via the Task Mainte- 
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nance & Status Reporting Gateway 550 and communicates 
with various service providers via the Transaction Service 
Provider Gateway 555. When the loan is finally closed (i.e. 
all designated tasks completed) this status is communicated 
to the Compensation & Task Performance Report system 
557 for the generation of these reports. The loan completion 
status is also communicated to the Secondary Banking & 
Loan Inventory Management system 563 which adds the 
completed loan data to the loan inventory and periodically, 
using a Secondary banking Engine 559, optimally packages 
certain loans for transfer to secondary funding sources. 

[0128] Having described a preferred embodiment and an 
alternative embodiment of the applicants invention, we now 
describe the major components in more detail. FIGS. 7-11 
indicate the basic original entry into the automated system 
and shows the kinds of data that is inputted. These data are 
then processed as follows. 

[0129] The 'Loan Application Gateway' 

[0130] Referring to FIG. 33, A loan originator, in any of 
several manifestations, may originate a mortgage loan 
request on behalf of a client, a 'borrower'. The 'Loan 
Application Gateway' provides for the Lender/Loan Origi- 
nator to enter his data and borrower data 3401 and envisions 
at a minimum, three (3) ways by which the system may be 
accessed by a loan originator; (1) via Internet website 3405 
of the assignee of the present invention, the data typically 
being in HTML format; (2) via custom-written software 
3403 which connects in a data transmission-enabled manner 
to the present invention and would typically be in XML 
format; and (3) via 'wireless' devices, including web-en- 
abled cell phones, wireless, modem-equipped hand-held or 
laptop computing devices, satellite communication devices, 
and other such wireless data and communication methods 
and devices 3407 as may come into common use, these data 
typically being in the WML or WAP formats, or other 
formats as may come into common use. The principle 
purpose of the 'Loan Application Gateway'3400, in serving 
as a portal, is to provide a way for the loan originator to 
exchange required data with to the 'Loan Application Sys- 
tem' without having to worry about what input method he is 
using and/or the related data formats and protocols. Conse- 
quently the major purpose of the input gateway is to perform 
the middleware tasks of — recognizing the input channel and 
data format and protocol used 3409 and convert the data to 
the standard Application Programming Interface (API) for- 
mat 3411 which will be used by downstream modules. This 
standard Application Programming Interface (API) format 
3411 is described in more detail below in the section 
covering the Compliance Engine. 

[0131] 'JTie input data originates from the input screens 
provided by the system. Upon making the connection to the 
Applicants system, the loan originator is presented with 
introductory screen sets ( FIGS. 7-12) and input screen sets 
(FIGS. 13-18) whereby the particular information which 
describes, to the Applicants system, the circumstances of the 
borrower, as well as the property under contemplation for 
purchase. Suitable reference and 'help' screens are made 
available to the loan originator to assist in the entry of 
required data. Notably, display information and on-screen 
prompts for data input are tailored to the nature and speed of 
the data link as well as the display limitations of the terminal 
device in use by the loan originator. 



[0132] Referring to FIGS. 7-18, such data or information 
is required for originating and underwriting a loan, and 
typically includes the following: a subscribing loan origi- 
nator's identification FIG. 7, pertinent information sufficient 
to identify the pending borrower FIG. 13, and information 
on the subject property FIG. 14. The subscribing loan 
originator's identification FIG. 7, in turn, provides the 
present invention with a profile of the originator and the 
location of the property m question thereby providing suf- 
ficient information to facilitate authentication of the origi- 
nator's qualification, according to regulations, to originate a 
loan, and otfier such information as is deemed necessary to 
logically connect the originator with agents, workers, or 
services which have been associated with the originator as 
'loan affiliates'. 

[0133] These 'affiliates' constitute a variety of resources 
which may be called upon on a loan-by-loan basis to provide 
services common in the industry, to the originator in order 
to complete the loan. 
[0134] The Authentication System 
[0135] In a preferred embodiment of the system, a Lender 
may make use of the Applicants system merely to obtain the 
set of tasks required for a specific loan, including tasks 
required by applicable federal and/or state law, and to obtain 
a Completion Certificate, or he may originate a loan through 
Applicant's network of Loan Originators also obtaining a 
Completion Certificate based upon the systems monitored 
performance of the required tasks involved. In either case 
the Loan Originator's qualifications are not verified by the 
Compliance Engine. That is, the Compliance Engine does 
not check the lenderid and property location to determine 
whether this Loan Originator is qualified to represent this 
loan applicant. 

[0136] In an alternative preferred embodiment, this 
authentication of the loan originator/lender is performed. 
This process will now be described. Upon completion of 
data entry by the loan originator, the Applicants system 
launches a validation or 'authentication' process 403 in FIG. 
4A and 503 in FIG. 5. The authentication module verifies 
the identity of the loan originator through the use of con- 
ventional means, a security 'login' typically requiring user 
names and passwords, which are programmatically verified 
as belonging to the loan originator. Various data security 
mechanisms may be incorporated in this sub-system as well, 
including the use of digital signatures as required. The 
completeness of the required input data is also verified. The 
Authentication module also authenticates the loan originator 
as being qualified to originate a loan for the property 
location specified. The module gets the loan originator and 
borrower input data 401 and calls the 'Compliance 
Engine'405, to determine whether the loan originator can 
originate this loan. If the initial queries to the legal context 
databases (these are described in more detail below with 
respect to the compliance engine description) indicate that 
the loan originator is not qualified then this "not-qualified" 
data is returned to the loan originator. If the loan originator 
is found to be qualified to originate loans in the locality a 
"yes" is returned and the authentication module may instruct 
the Compliance Engine to complete a "worker profile" for 
this loan originator, borrower and property. 
[0137] The Automatic Compliance Engine 
[0138] The Automatic Compliance Engine (the "Compli- 
ance Engine"), (458 in FIG. 4C and 520 in FIG. 5), is now 
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described in a preferred embodiment, llie Compliance 
Engine is called a number of times by several modules. 
[0139] As described above, many government, profes- 
sional, and business institutions impose requirements on 
land and mortgage lending transactions. A requirement can 
be the disclosure of specified information to the borrower, 
filling out a required form, or the gathering of specified 
information, to name a few. Applicants retains the services 
of legal professionals throughout the country who continu- 
ously gather these requirements and organize them into a 
comprehensive rule base. The purpose of the Automated 
Compliance Engine is to apply these rules in an automated 
way to identify' all requirements that apply to a specific loan 
and to track the completion of those tasks. The output of the 
engine is a task list comprised of all the tasks which the 
engine has determined need to be completed for a specific 
loan, augmented with task completion information for com- 
pleted tasks. 

[0140] In a preferred embodiment, the task list is prepared 
by selecting a subset of tasks from the list of all task 
definitions known by the Automated Compliance System. 
Tasks arc selected by evaluating expressions written in a 
dynamically interpreted programming language that test 
facts pertaining to the specific loan information. If the 
expression evaluates to true, then all tasks associated with 
that expression are added to the task list. All of the expres- 
sions in the rule base are sequentially evaluated for each loan 
instance. The Automated Compliance Engine is thus a rule 
based system, where each expression represents the 'if part 
of a rule, and the subset of tasks associated with the 
expression represents the 'then' part of a rule. 
[0141] Tor example, the following is a set of tasks for a 
given context: 



cessing and simply wants Applicants to monitor task 
completion, or it may be an automatic transmission to an 
automated workflow process engine. In a preferred embodi- 
ment, the automated workflow process engine may be 
Framework™ Inc.'s "T-endware™" program or a functional 
equivalent, such as one based on Forte Software™ Inc.'s 
Forte Conductor™ product. In this case the Workflow pro- 
cess engine presents the tasks to the persons identified as 
being responsible for doing the task. 
[0144] As each task is completed, the Compliance Engine 
receives notice of the completion event and the task list is 
updated to include the identification of the person complet- 
ing the task and the date and time of completion. The task 
list is considered completed when all required tasks have a 
completion date. Compensation may be issued to those who 
performed specified tasks with assurance that all required 
tasks have been completed and that the compensation is 
within the bounds of the laws and policies of the participat- 
ing institutions. 

[0145] Data Representation 

[0146] In the preferred embodiment, all Compliance 
Engine inputs and outputs are in represented externally in 
Extended Markup Language format (XML) which is 
described in the document found at www.w3.org/rR/1998/ 
REC-xml-19980210 which is incorporated fully herein by 
reference. XML provides an extensible hierarchical data 
structure where each element of information is labeled with 
a tag and optionally contains a value and any number of 
child elements. Internally, the same information is repre- 
sented and manipulated in a standard tree format using the 
Document Object Model tree (DOM) which is described in 
the document at www.w3.org/TR/REC-DOM-LeveI-l/ 
level-one-core.html#ID-1590626202 and which is incorpo- 



■dd>12</id> 

<tf>valCloaa.property.addres5.state')=TXVif> 

<taskNamc>TX Mortgage Broker/Loan Officer Disclosure</taskName> 
<taskNamc>Pioperty Disclosure-Seller io Buyer</taskName> 
<taskName>nWtaskName> 
<taskName>URLA</taskName> 

<taskNamc>Right to Receive Appraisal Disclosurc</taskNamc> 
<taskNamo>TX Residential Construction Contract Disclosurc</taskNamc> 




[0142] Once required tasks are identified, the engine 
applies lender task profiles in order to override task descrip- 
tion, the URL to print a form, and other task information 
provided in the standard task definitions with more specific 
values from the Lender Task Profiles. This allows a high 
degree of flexibility in customizing the engine for specific 
lender requirements, including changing the wording of the 
description of the task or changing the form that must be 
filled out. 

[0143] Once the task list has been initially prepared, it is 
presented to those persons responsible for completing the 
tasks. This may be as a simple task fist transmission to a 
lender who is doing his own loan origination and/or pro- 



rated fully herein by reference. Conversion between internal 
and external representation is provided by output methods of 
the DOM tree implementation and input methods of the Java 
API for XML Parsing (JAXP) which is described in the 
document at the URL java.sun.com/xml/docs/api/ which is 
incorporated fully herein by reference. 

[0147] For convenience in referring to DOM tree ele- 
ments, but not of necessity, the tree implementation is 
extended to provide easier tree traversal using a simple 
"get(String path)" method that takes a path argument such as 
'lask.name'. The tags between the dots '.'are parsed out of 
this path and used to search for corresponding elements in 
the tree. In this example, the get method searches for the 
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first-occurring element of the tree with tag "task". Once 
found, the get method then searches for the 'name' tag 
among the child elements of the 'task' element, and so on for 
all the tags listed in the path. Further descriptions herein will 
use this path notation to refer to specific data elements in the 
data model trees defined below. 

[0148] Alternative ways to represent and access the infor- 
mation could include files, objects, database records, arrays, 
structs, TCP/IP socket streams, 'if-then-else' statements in a 
programming language, or other ordinary means for repre- 
senting structured information. 
[0149] Data Mode 

[0150] In recognition of the need to automate as many of 
these activities as possible, to the mutual advantage of the 
real estate and mortgage loan community, the Mortgage 
Bankers Association of America (MBAA) recently origi- 
nated an effort to develop data structure standards to provide 
standardization of common business transactions in the 
mortgage industry. ihis effort is coordinated by a workgroup 
of mortgage industry representatives and is called the Mort- 
gage Industry Standards Maintenance Organization 
(MISMO). Initial deliverables of MISMO include 1) an 
XML Transaction Architecture to encompass data exchanges 
from loan origination, the secondary market and servicing; 
2) a data dictionary to provide business definitions and 
corresponding tag names of each of the data elements 
included in the architecture; and 3) a data model to provide 
relationships between the elements in the business data. The 
current versions of these deliverables are contained at www- 
.mismo.org and are fully incorporated herein by reference. 
[0151] 'ITiis description refers to the detailed data model in 
the MISMO web site mentioned above (www.mismo.org) . 
The Data Model is described therein as follows: 

[0152] "The Data Model is a tool used to understand 
the relationships between the data elements in the 
data dictionary. It is a reference to aid in building the 
XML DTD's. This is not the XML implementation 
of the MISMO Standard.." 



[0153] 


MISMO Data Model Documentation 


[0154] 


Address 


[0155] 


Address Definitions 


[0156] 


Agreement 


[0157] 


Agreement Definitions 


[0158] 


Entities Attributes 


[0159] 


Entity Listing 


[0160] 


MBA Data Model 


[0161] 


Credit Report 


[0162] 


Party 


[0163] 


Party Credit Definitions 


[0164] 


Party Declarations Definitions 


[0165] 


Party Finance 



[0166] Party Finance Item Definitions 

[0167] Party Person Definitions 

[0168] Product 

[0169] Product Definitions 

[0170] Property 

[0171] Property Definitions 

[0172] MBADataModel vl.ERl 

[0173] The Compliance Engine XML/HTTP Transaction 
API described below includes Example values for clarifica- 

[0174] The core knowledge of compliance requirements is 
represented in the 'rules' structure, consisting of 'rules.con- 
lexts' and 'rules.operations'. Each 'rules.conlexls.conlext' 
represents an if/then rule, where the 'context.if part 
describes a specified loan situation (context), and the 'con- 
text.then' part is a list of 'taskname' references to the tasks 
that are required in that context. Each 'contextif ' definition 
is expressed in a programming language statement that 
examines the facts of a specific loan and evaluates to true or 
false, as described in the algorithm description below. 

[0175] Each 'rules.operations.task' defines detailed infor- 
mation about a specific task, independent of the contexts in 
which it may be required. This information includes a 
description of the task, a URL link to any forms that may be 
required for the task, a time period within which the task is 
expected to be completed, and potentially other information 
pertinent to a task. References from the context structure in 
each 'rules, cantexts.context.then.taskname' are matched 
with the corresponding name in 'rules.operation- 
s.task.name'. In this manner, a detailed task definition is 
associated with one or more specific contexts, by task name 
reference. 

[0176] This separation between tasks and contexts is a 
convenience that allows a task to be defined in a single place 
yet be associated with multiple contexts. Alternatively, the 
'rules.operations' list could be eliminated by replacing every 
'niles.contexts.context.then.taskname' with an equivalent 
'task' structure as presently defined in 'rules.operation- 
s.task', although many of the tasks would need to be defined 
and maintained redundantly in this mode. 

[0177] Elements of a 'rules.operations.task' definition 
may be overridden by a corresponding element in an 'over- 
ride.tasks.task' definition whose 'rules.operation- 
s.task.namc' matches the 'ovcrridc.tasks.task.namo'. This 
allows customization by supplying customer-specific infor- 
mation in the task definition, such as a customer-specific 
form, description in more familiar language, or any other 
task definition element. Any number of 'override' structures 
may be applied in sequence, each overriding the result from 
the previous 'override' application. This allows overrides 
from customers, and their brokers, agents, and other affili- 
ates to be applied in any desired priority ordering that 
ultimately determines which override changes will be final. 
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The method of applying the override information is 
described in the algorithm below. 

[0178] The 'loan' structure contains all the information 
pertaining to a specific loan application. The loan applica- 
tion contains information about the borrower, the property to 
be mortgaged, its location, the loan amount, and the type of 
loan applied for. This is the information that is evaluated by 
the 'rules.contexts.context.if' expression to determine 
whether the conditions specified in the context definitions 
are true in the case of a specific loan. 
[0179] Compliance Engine XML/HTTP Transaction API 
[0180] The Compliance Engine Application Program 
Interface (API) defines structures for communication 
between the Automated Compliance Engine and the external 
environment. The request is initiated by an external agent 
with accompanying request parameters described below, and 
the response is a complete Task Status Report consisting of 
the 'tasks' list output of the engine plus the completion 
information of completed tasks. Each output 'tasks.task' 
defines a task that the engine has determined is required in 
the case of the specified loan. The list will typically be a 
subset of all defined tasks. Each task includes the detailed 
task definition information from 'rules.operations.lask', 
with some elements possibly overridden by corresponding 
task override information from 'override.tasks.task'. 
[0181] Data is exchanged via pre-authenticated HTTP in 
XML format (DTD available). It is presented in indented 
format for readability. All XML elements are required. 
[0182] The lender must provide, for each loan product, a 
description containing the product attributes that are 
required for compliance analysis, such as whether ARM, 
fixed, balloon, index, etc. Each loan application is linked to 
this information via the loanproductld compliance param- 
eter, described below, lhis must be updated whenever the 
product attributes change. 

[0183] The MISMO standard mentioned above contains 
most of the information required by the Compliance Engine 
to perform its work, but not all. The key missing pieces are 
the type of loan product the borrower is applying for, and the 
lender and agent identification. 



[0184] Loan products differ from each other in terms of 
whether they are adjustable rate (ARM) or fixed, whether the 
rate is tied to T-bills or some other index, whether there is 
a Balloon payment, whether the property will be owner 
occupied or rented out, whether there is cash out or not, etc. 
[0185] The loan product information is complex, and there 
are several compliance rules that arise out of different 
characteristics of the lender's loan product. In a preferred 
embodiment, rather than try to identify all facets of the loan 
product in a structured way and apply rules each time those 
facets are examined, instead, the loan product information is 
analyzed by hand, one time, up front, and a decision is made 
as to what compliance tasks are required for that type of 
loan. Then when it's time to generate a task Est, there is a 
single rule that indicates if you have loan product type XYZ 
then you must do tasks 1, 2, and 3. The main piece of 
information that is not provided by MISMO is the loan 
product ID, which is the id given the loan product by a 

[0186] Besides the loan product ID, the compliance API 
also requires the lender id, which is used in conjunction with 
the loan product id to fully identify the loan product, and it 
also tells us where the loan originator's pay will come from, 
which lender profile to apply, the lender to send notifications 
to, etc. The API also requires the loan originator agent id, 
which identifies who the loan originator is so he/she can be 
paid appropriately when that time comes. The loan origina- 
tor id is assigned by Applicants. 

[0187] The lender may also provide a task list profile that 

defines override values for task.description and task.fonn for 

any task. These values override the Applicants default values 

for these fields, if present. This allows lenders to describe 

tasks in their preferred terminology and to use their own 

forms, subject to compliance requirements. 

[0188] These data provided via the Loan Application 

Gateway 3400 (described above) include the following 

exemplary type data: 

[0189] New Task List Transaction 

[0190] This transaction creates a new loan compliance 

record in the Applicants compliance database, and creates 

the task list. 

[0191] Input: 



mplianceRequest 

requesrType newTasklist //same as HTTP Request-line URI resource 
lender (loan) 

Icndcrld //oncpipclinc assigned 

Icndcrlxianld //lender assigned 

agenlld //loan originator, onepipeline-assigned agenlld 

"l //loan compliance parameters. 

loanOriginationFee //$. Requires review if over 1% of loanAmount. 

loanProductld //must match id in lender-provided product 
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[0192] Output: Task Status Report (see below) 
[0193] Update Transaction 

[0194] This transaction updates the loan compliance 
record when one or more tasks are completed, or when loan 
compliance parameters are changed. If loan compliance 
parameters are changed, a new task list is generated, and the 
old one is moved to the taskListArchive section. Task 
completion information is retained in both the current task 
list and in the archived task lists. 
[0195] Input: 



[0196] Output: Task Status Report (see below) 
[0197] Task Status Report Transaction 
[0198] Output: 

[0199] Format and structure is the same for all transaction 
types. When changed loan compliance parameters require 
regenerating the task list, old task lists are preserved in the 
taskListArchive section. Completion information is present 
only for completed tasks, in both tasks and taskListArchive 
sections. 



//matches taskld from [ask in task list 

//onepipeline agent id 

//date and time in SQL format 



MnOrigirraiionFee //$. Requires review iT over 1% of 

loanProductld //must match id in lender-provided product 

ropcrtylypc //single, multiple, occupied, etc., from list 

nancingOptions //cash out, refinance, purchase, etc., from list 

//2-letter postal state code; NY, CA, TX, etc. 



>mplianceResponse 

requesflype taskStatusReport 
httpStatus 



taskld 

taskName 

display-Sequence 



completedDate 



//may be overridden via lender profile 

//.PDF printable form URL. May be ovei 

//HUD step 1, 2, 3, 4, or 5 

//Present only for completed tasks 

//onepipeline agent id 

//date and time in SQL format 



taskListArchive 
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iks //same as tasks structure above, as of date 

in (loanProductData) //same as request, with replaced loanProductld 



stepCompletion (completion) 
step (stepNumber x) 

stepNumber //HUD steps J, 2, 3, 

complete //Y or N 

feePercent //percentage ti 



loanOriginationFee, $ 
/,'onepipeline agent id if agent completed 
//fee $ if agent completed, else zero 



[0200] Algorithm 

[0201] Refer to the description of XML, JAXP, and DOM 
in the data representation description above, and to the data 
model description and detail data model elements also 
described above. 

[0202] At startup, the Automated Compliance Engine 
reads the XML-formatted 'rules' from external storage into 
memory. This XML stream is parsed by the JAXP parser into 
a DOM internal tree. For each 'rules.operations.task', the 
'task.name' is used as a key in adding task detail definition 
elements to a java.util.Hashtable to enable looking up a task 
definition by 'task.name'. Similarly, an array is loaded with 
each 'task' indexed by 'task.id', to enable looking up each 
task by the unique 'task.id' integer value. A separate hash- 
table is loaded with task override information for each 
lender, again using the 'task.name' as the key. Also, a socket 
connection to a network is opened by a web server or other 
HTTP service to enable Compliance Engine users to submit 
requests to the Compliance Engine server and to return 
responses. HTTP socket connections are describer described 
in the document found at www.w3.org/ProtocoIs/rfc2616/ 
rfc2616.html and which is incorporated fully herein by 
reference. 

[0203] Once initialized, the Compliance Engine server 
operates in a stateless request-response fashion, similar to a 
web server, following the HTTP protocol. Alternative pro- 
tocols could be used. The request and response are both 
formatted externally in XMI. format, and internally in DOM 
trees, as described in the data representation description 

[0204] The Compliance Engine API provides for three 
different request types: New Task List, Task Completion, 
and Task Status Report. These are described below. The 
response in all cases is a Task Status Report containing a 
'tasks.task' list. The remainder of this algorithm section 
describes how the task list is created or updated in response 
to these requests. 

[0205] The Compliance Engine also incorporates an 
'event generation mechanism', the purpose of which is to 



trigger actions upon the occurrence of specified events. 
These events may include a 'pushed' report where a task list 
is periodically updated according to specified parameters 
and delivered. 
[0206] New Task List 

[0207] The New Task List request consists of a 'loan' 
structure that contains information about a specific loan 
sufficient to determine which compliance tasks are required. 
[0208] The 'tasks.task' list is prepared as follows. Each 
'mles.contexts.context.if expression is evaluated, one at a 
time, in a loop from first to last. The 'if expression is written 
in the JPython programming language, which is an inter- 
pretive scripting language thai can evaluate string expres- 
sions at runtime. The Python Programming Language is 
described in the book "Internet Programming with Python" 
by Aaron Waters, Guido van Rossum and James C. Ahl- 
strum, M & T Books (Div. of Henry Holt & Co.) 1996, 
which is incorporated herein by reference. Other languages 
could be used. The expressions typically reference a specific 
element in the 'loan' structure to see if the element contains 
a specific value. 

[0209] For example, to determine if the loan property is in 
the state of Utah, the expression could be "val('loan.prop- 
erty.address.state')=UT'". The "val() method takes a string 
describing a path into a DOM tree, and returns the first value 
of the first DOM node found on that path. If the actual value 
of the 'loan.property.address.state' node of a specific loan 
was 'UT', the expression evaluates to true, otherwise false. 
When such an 'if expression evaluates to true, all of the 
associated 'rules.contexts.context.then.taskname' references 
are followed by using the 'taskname' value as a key to look 
up the referenced task detail definition through a java.util- 
.Hashtable populated at startup. 

[0210] After finding the task detail in the hashtable, the 
'rules.operations. task.name' task detail definition structure 
could be copied directly to an output task list; however, for 
convenience in the preferred embodiment, the integer value 
of the included 'rules.operations.task.id' element is used to 
set a corresponding bit in ajava.util.BitSet. This 'id' integer 
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value is unique for each task in the 'rules' set. After all rules 
have been evaluated and all applicable bits are set, the 
resultant BitSet contains a true bit for every task with a true 
'if expression. The BitSet thus represents the subset of all 
tasks which the Compliance Engine has determined to be 
required in the case of the specified loan. The purpose of this 
BitSet representation is to allow, in the future, rapid and 
simple boolean operations (and, or, or not operations on the 
BitSet) to combine task lists from different rule sets to 
improve flexibility and/or increase performance. One way to 
increase performance, for example, is to create a BitSet at 
startup time from a rule set that contains contexts that are 
always true for every loan. This initially created BitSet can 
be combined with the dynamically created BitSet using a 
bitwise 'and' operation in a manner that avoids unnecessary 
re-evaluation of some rules. 

[0211] Once a final BitSet is constructed, the program 
loops through each bit in the BitSet, and where a true bit is 
found in a particular bit position, the bit position is used as 
the index to retrieve the corresponding 'task' definition 



structure from the array that was indexed at startup time 
using the matching 'task.id' integer value. This 'task' detail 
definition structure is then copied and the copy appended to 
the DOM output tree containing the output task list. 
[0212] After constructing the list of task detail definitions 
for all required tasks, the task override information is 
applied. This is accomplished by iterating through each task 
on the output task list, and looking up the task override 
information for the lender specified in the request. If a task 
override structure is present in the table, then the program 
loops through each element in the override structure task 
definition and replaces the corresponding element in the 
output task definition. For example, if the override task 
structure includes a lender-provided task description, then 
the value of that description is copied over the top of the 
more generic description from the original rules structure. 
[0213] Exemplary Task List 

[0214] An exemplary task list generated by the Compli- 
ance Engine in a preferred embodiment is as follows: 



<name>all loan: 
<if>true</if> 



<tasiName 
<taskName>Transfer of Servic 
<taskName>ELN</taskName> 
<lasliName>ECOA</lasiName 



<id>57</id> 

<namc>Wyoming</Bamc> 
<if>statc ('WY')</if> 

<taskNamc>TEL</'tasiName> 
<taskName>URLA</taslcName> 

<taskName>Riglit to Receive Appraisal Disclosure</taskNam 
<taskNamc>Financc/Lock-in Disdosurc</taskNamc> 
</then> 



<if>valOloan.property.address.sl 

<taskName>TX Mortgage Bit 
<taskName>Property UUclosi 
<taskName>TIL</taskName> 
<taskNamc>URLA</tasl£Nam 
<tasl[Name>Right to Receive Appraisal Disc; 
<taskNanie>TX Residential Construction Cm 
Disclosure</laskName» 
</then> 



<if>((val('loan.property.address.state") == 'TX') & 
(ival('loan.loanAmount') > 50000))</if> 

-in Oisclosure</taskName> 
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<id>56</id> 

<nome>TX Commitment/Lock-in Disclosure</name> 
<description>The borrower must receive a Commitment/Lock-in 

<Eorm>http://forms.onePi 
in_Disdosure.pdf </form> 



<description>The borrowers) must sign and return the 
completed Uniform Residential Loan Application. <,'deseription> 
<rorm>hltp:/.'forms.onePipeline.mm/FNMA_n003.pdr<,'rorm3 



<reePercent>10</feePer(;enl> 
cnametoFF.</name> 

<description>The borrower must receive the Good Faith 
nstimate.</description> 

<form>http://fornis.onePipeIme.convGood_Faitli_Ei>timate.pdEc/foim 



<namc>Transfcr of Servicing Disclosurc</namc> 
<description>The borrower must complete, sign, and return 

closing. <.'dcscription> 

<form>http^/forms.oneFipeiine.com/Servieing_Disdosure_552R.pdf</ 

<role>originator</role> 
<feePer " " 



<description>The borrower must receive the Fair Lending 

tm>http://forms.onePipelme.com/Fair_Lending_Notice.pdf<,'forn 
<feePercent>5 </feePercent> 



<id>7</id> 

<name>ECOA</name> 
<description>The borrow 
Opportunity Act dil " 



Disdosure.</de.scriplion> 
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<origi_torDays>30< 



<description>The borrower must receive the Finance/Lock-in 
n>http://fonns.oriePipelke.cor£VFiiiance_l^ct_iii_Disolosur 



<id>55</id> 

<I»me>TX Mortgage Broker/Loan Officer Disclosure. 

<description>The borrower must receive a Mortgage 
Broker/Loan Officer Disclose re. </descriplion> 
<fomi>hllj 1 ://rnrins.onePipdin c .c l )rri/TX_Mortgage_Br(>kci 

_Disdosure_m4STX.ixlf<,'forni> 
<reePercenl>5</reePercenl> 



rust be completed and 
y Disclosure Seller to 



<feePercent>0 </fcePercent> 



ct Disclosure, which is to be provided by the 



<name>TX Mortgage Broker/Loan Officer Disclosure</name> 
<description>Execute ABC Company Loan Officer 
Disclosure.</description> 

<form>htt P ://forms.ABC.com/'ABC_Loan_0£acer_Disclosure.pdf</form> 
<role>Loan Originator</role> 



itial Construction Contract DisclosureWnam 
mist receive the ABC Company 
Disclosure. «/description> 




.ABC.com/ABC_Residential_Constroction_Contract_D 
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[0215] In a preferred embodiment, the original compliance 
task list for a specific loan is transmitted to the lender for 
Compliance Management or passed to an automated work- 
flow engine to initiate the dynamic workflow process. FIGS. 
37-41 contain a set of system screen shots showing an 
exemplary list of tasks required to complete a sample loan. 

[0216] An Alternative Embodiment 

[0217] In an alternative embodiment, a more general com- 
pliance system may be used, and is now described with 
reference to FIG. 5. Referring now to FIG. 5, the 'Origi- 
nator and Processor Compliance Engine'520 is comprised of 
two principle elements — the 'Worker Description' 521 and 
the 'Legal Context'523. These elements are described in 
their preferred embodiments as follows: 

[0218] The 'Worker Description '521 comprises an assem- 
blage of data sources which define the typos 525, roles 527 
and locations 529 of the workers or agents which may 
participate in the mortgage origination process. The partici- 
pation decision for a worker or agent is based upon the 
combination of features which the worker embodies and 
which make them unique when combined one with another. 
In the preferred embodiment, the worker provides a data 
prof I l r I the worker's type— that is, the type 

of service the worker may provide. The worker is typically 
representative of only one 'type' for example, either a 'Real 
estate sales professional', 'mortgage broker', 'banker', etc.. 
The specific 'role(s)' that a particular worker or agent has in 
the process is/are also defined. The 'role(s)' that a worker 
assumes arc aligned with the tasks requiring completion 
which a worker of that type can legitimately perform, 
according to the governing rule base for that specific worker 
type. These 'roles' may include such tasks as surveys, 
inspections, credit worthiness checks, employment verifica- 
tion, etc.. Orchestrating the interrelationship of these infor- 
mation sources is a 'Role Sequencing' definition or data 
table which assures a meaningful, orderly, and legal appli- 
cation of the available data. Those skilled in these arts will 
understand that various methods similar to those described 
above ill a preferred embodiment could be used for such 
sequencing activities. In an exemplary process the data 
passed from the Authentication module includes the loan 
originator used ID. This user ID is used as an argument to 
find the recorded worker type in the Worker's description 
databases where a user ID I, for example, would produce a 
Type ID1. This type ID1 would then be used to find the 
corresponding roles for this type of user and to determine the 
locations where this user id is licensed/qualified to do 
business. These data are written into a 'worker's profile' 



[0219] Referring again to FIG. 5, the 'Legal Context'523 
could comprise an assemblage of data sources which would 
contain the regulatory elements pertinent to the compliance 
and underwriting process as required by the 'Originator and 
Processor Compliance Engine'520. Included in this element 
would be tables and other data sources which are typically 
comprised of state and county regulations 531 similar to 
those described above with reference to the preferred 
embodiment, licensing regulations 533, federal regulations 
535, and professional organizational rules 539, all of which 
may govern or otherwise influence the underwriting process. 
Orchestrating the interrelationship of these information 
sources would be a 'Rule Sequencing' engine 541 which 
assures a meaningful, orderly, and legal application of the 
available data. When the 'Role Sequencing' data table and 
'Rule Sequencing'541 engines have completed the required 



processing, a profile 543 or a composite of the borrower 
requirements and property profile with applicable worker 
attributes is made available to the other modules as required 
(i.e. the Authentication module, Loan Origination module, 
workflow engine, and Task maintenance & status reporting 
gateway module). 

[0220] The 'Loan Application & Program Matching Sys- 
tem' 

[0221] Referring again to FIG. 4C, the 'Loan Origination 
& Program Matching System'456, (also see 505 in FIG. 5) 

is comprised of a multiplicity of sub-systems, to be later 
described. After this loan originator has been 'authenticated' 
as described above, this system serves as an infrastructure to 
identify various loan products or instruments suitable for 
this unique combination of borrower and property, and 
further offering a preferred recommendation of loan prod- 
ucts and participating workers or agents to effect the loan. 
The system communicates with the loan originator and 
requires him to complete the actions and provide the addi- 
tional borrower data and instructions shown in FIGS. 12-17. 
[0222] As indicated above, in the preferred embodiment of 
the invention, this Loan Application & Program Matching 
System' is preferably performed by a system such as GHR 
Systems™ making use of their PrcmicrWarc™ product. This 
GHR product is also an object oriented product, however the 
objects employed are Microsoft COM™ objects which 
require Windows NT™. The web server architecture of 
applicants system is UNIX based which necessitates using 
Java and the Common Object Request Broker (CORBA) 
system to communicate between the UNIX and COM based 
object systems. The architecture of this communications 
interface is described below with reference to FIG. 34. 
[0223] With reference to Applicants's use of this Premier- 
Ware™ product, the following description pertains. The 
input and output data elements that play a role in Applicant's 
use of the GHR Underwriting Framework known as Pre- 
mierWare are now described. Applicants implemented the 
framework within a distributed architecture encompassing 
several technologies including Java, CORBA, COM, and 
Delphi (Object Pascal). First, how the GHR components 
interact with each other arc described, followed by the 
Applicants implementation around that interaction. 
[0224] GHR Systems' PremierWare framework is a set of 
software components that adhere to the component object 
model (COM) sponsored by Microsoft. Inc. The framework 
is provided to facilitate the qualification of borrower cre- 
dentials, i.e., income, debts, etc., against mortgage loan 
programs. The desired result being to locate a loan program 
for which the borrower is qualified. The framework is 
functionally divided internally representative of three pri- 
mary operations: 

[0225] Product Filtration: Narrowing the number of 

programs available for qualification processing. 
[0226] Qualification: Extracting the programs for 

which the borrower is qualified to apply. 
[0227] Ancillary Utilities (Helping): Packaging and 

unpacking data as it moves in and out of the GHR 

API. 

[0228] Product Fileration 

[0229] If no product filtering is performed before qualifi- 
cation, then qualification processing is completed on all 
products in the GHR products database. Filter criteria can be 
set using any or all of the data elements below: 
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PropertyCounty 

PropertyZip 

LocKType 

LockDoys 

PricePreference 



ProgramlD 

POC (Product Group 

Code) 



FixedRateMo rtgages 
AdjuslableMorlgages 
BaloonMortgages 



[0230] The result of a Product Filtering operation is a set 
of loan programs that serve as the input to a Qualification 
operation. Within the framework, the Pricer object's Get- 
ProductsForQualification method is used to perform a fil- 
tering operation. Once a set of loan programs is received 
from GctProductsForQualification, then qualification can 



[0231] Qualification 

[0232] The first step in qualification is selecting a Quali- 
fication Method. There are fourteen methods in total, which 
are grouped into four Modes. The four Modes are: 

[0233] Buyer/Purchase 

[0234] Cash out Refinance 

[0235] No Cash out Refinance 

[0236] Shopper 



EstimatedTaxDollars 

EstimatedHazInsDollais 

VASlaUis 

AssodationFee 

FlCOScore 

FICORejectCnde2 
FICORejeclCixle.l 



Boolean 
Boolean 



Buyer/Purchase Mode 
BuyerAvailableCash Qualification Met 
Qualifies a borrower based on his/her cash av 



BuyerMaxLoan Qualification Method 



Buyer/Purchase Cash out Refinance No Cash out Refinance Shopper 

BuyerBaseLoan CashoutRefiMaxCashout NoCashRefilnclFee Shopper 

BuyerAvailableCash CashoutRefiSpecifyCashout NoCashRefiSpecifyLoan 

BuyerMaxLoan CashoutRefiSpecifyLoanAmt NoCashRefiSpeciryLTV 

BuyerBaseLTV CashoutRefiSpecifyLTV NoCashRefiNoCostRefi 
BuyerDesiiedPrn 



[0238] The grids below and on the following pages outline 

these modes and the various methods available in each -continue d 

Mode with each method's input parameters. There is a core Qualifies a borrower for the maximum loan amount 

set of input parameters that are Used for all methods, and All Properties are the same as the BuyerBaseLoan except 

then under each method, there are one or more variations BascLoan is removed. 

that are indicated in context. ~ ' ~~ ~ 
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Al! Properties are the same as th 



percentage of download 
BuyerBaseLoan except 



Inte 



Buyer/Purchase Mode 
BuyerDesiredPITI Qualification Method 
Qualifies a borrower based on his/her desired monthly 

All Properties are the same as the BuyerBaseLoan except 
^ BaseLoan is replaced by DesiredPITI. 



iiredPm 



Shopper Mode 
Shopper Qualification Method 
Qualifies a borrower who is shopping for a house and does not 
have a specific property. Also known as "affordability analysis " 
All Properties are the same as the BuyerBaseLo tn except 
BaseLoan is removed but MaxLTV, MaxPITI, and AvailableCash are 
added as well as two percentage fields: EslimaledTaxesPercent and 
RMimatolHa/.InsPetcent and n MaxPoinLsAsOift field. 



OHR Term 



Date Type 



EstimatedTaxesPerce 
EstimatcdIIazInsPerc 
MaxPointsAsOift 



No Cash Out Refi M 



Qualifies a borrower with a : 



FICORejectCodel 

FICORejectCode2 

FICORejectCode3 

CurrentMtgBalancel 

CurrentMtgBalance2 

CurrenlMtgBalance3 

CurrentMtgRatel 

CurrentMtgRate2 

CurrentMtgRate3 

CurrenlMtgPrni 

CurrentMtgPITO 

CurrentMtgPm3 

CtirrenlMtgRemaiaiiigT 

QrrrentMtgRemainingT 

CurrenlMtgRemainingT 

CurrentMtgEI.OC_2nd 
CurrentMtgELOC_3rd 
CurrentMtgToBePaidOf 

CurrentMtgToBePaidOf 
£2 

CurrentMtgToBePaidOf 



String 



in Buyer Mode 

Defined 

in Buyer Mode 



RequestedPoints 
RequestedCeiling 



in Buyer Mode 
in Buyer Mode 



Defined 

in Buyer Mode 

Defined 



No Cash Out Refi Mode 
NoCashRefiSpecifyLoan Qualification Met 
ifies a borrower with a specified refinance la 
roperties from NoCashReflncludeFee remain 



MonthlyDebt 
CurrentHsgExpense 

YearsExpectedinHouse 



IgnoretncomeRatios 
FrontRalioOverride 



in Buyer Mode 
in Buyer Mode 
in Buyer Mode 
in Buyer Mode 



In Buyer Mode 
Boolean Defined 

in Buyer Mode 
Boolean Defined 



No Cash Out Refi Mode 
NoCashRefiSpecifyLTV Qualification Method 
lifies a borrower with a specified percentage of ex 



No Cash Out Refi Mode 
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allows the closing 



k as the NoCashReflncludeFee 



Cash Out Refl Mode 
CashoutRefiSpecifyCashout Qualification Method 
Qualifies a borrower with an amount that will pay off the 
;ting loan balance with a specified cash out to the borrowe: 

Pi erti are th to tn CashRefl del «■ ■ 
qualificati on mcl hud plus an AvailabteCash field. 



Dale Type 



Cash Out Rcfi Mode 
CnshoutRefiSpecifyLlV Qualification Method 
Qualifies a borrower with a specified loan to value ratio, 
nple: 7U% urv for an existing loan balance of $70,U00 will rei 



[0239] Credit Profile Inputs 

[0240] Each of the qualification methods also accept two 
input arrays for specifying aspects of the borrower's credit 
profile. These elements improve the accuracy of the Quali- 
fication Results. A Credit Report is retrieved electronically 
from a certified credit-reporting agency and prepared for use 
by the GHR interfaces. The two array elements are: 

[0241] Liabilities 

[0242] Public Records 
[0243] The data elements for setting these arrays are 
provided below: 

[0244] Liabilities 
[0245] SetNumberOfRecords(Integer); 



[0246] BorrowerNumber 

[0247] LateDaysLiabilityTypeMonths- 
FromDateReported 

[0248] Public Records 

[0249] SetNumberOfRecords(Integer); 

[0250] BorrowerNumber 

[0251] MonthsRecordClosed 

[0252] MonthsRecordOpened 

[0253] RecordType 

[0254] Amount 

[0255] GHR Qualification Results 

[0256] Two sets of records are returned from each quali- 
fication request. A set of products (Loan Programs) and a 
corresponding set of closing costs. There is a one-to-many 
relationship from each Ix>an Program to the array of Closing 
Cost Records. The layout of these fields is depicted below: 



PreQualOulpul Record Qmn Programs) 

RejectionFlags Integer 
TotalLoanAmount 
BaseLoanAmount 
SalePrice 
Cl05ingCosts 

StartingPrn Integer 



Ml 

■taxes 
Hazlns 
RequiredCash 

PrnReserves 
OriginationFee 
UpfrontMI 
MIFinanced 

QualRate 



BreakEvenMonthNoRein 
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PaidOutsideClosini 
VHAAllowable 
AppliesToMods 
Financed 



FromZip 
Mortgagee 



Boolean 
Boolean 
Boolean 



[0257] Applicants Implementation 

[0258] In Applicant's architecture, the GHR components 

are wrapped with a CORBA interface using Borland's 

Delphi development tool (Object Pascal). This interface 

exposes a single method 'Qualify' that accepts five input 

parameters: 

[0259] Qualification Method 

[0260] Filter Parameters 

[0261] Qualifications (Borrower Data) 

[0262] Borrower Liability Data (From Credit Report) 

[0263] Borrower Public Record Data (From Credit 
Report) 

[0264] With the exception of 'Mode', which is an integer 
value, all the other parameters are Strings. The Strings are 
formatted (delimited) with structures to be easily disas- 
sembled for use against the GHR COM interfaces. The 
format makes use of industry standards such as XML and 
XMLT Data is sent to and" from the CORBA interfaces 
utilizing HOP over TCP/IP. 

[0265] Any CORBA client can tie directly into the GIIR 
CORBA server once the input parameters are satisfied. In 



our implementation, a set of JavaBeans comprise the client 
side of our architecture. There is a JavaBean representing 
each of the Qualification Methods expressed by GHR. The 
JavaBeans expose mutater methods for setting each element 
of the input parameters for Filter Parameters, Borrower 
Liability Data, Borrower Public Record Data, and Qualifi- 
cations. The Qualification Mode is encapsulated within the 
JavaBean corresponding to the GHR qualification method. 
All of the JavaBeans expose a QualifyO method through 
inheritance that performs all of the CORBA location and 
marshalling functions necessary to interact with the GHR 
CORBA Server. The result of the QualifyO method call is a 
delimited String representing the 'PreQualOutput Records' 
and 'Closing Cost Records' described above. Navigating the 
output is facilitated by a special IqualifiedProducts JavaBean 
which receives the formatted return String, parses the 
records, and exposes methods for accessing individual ele- 
ments of semantic importance as also outlined in Qualifi- 
cation Results section above. These JavaBeans are depen- 
dent on the visibility of the GHR CORBA Server via an HOP 
channel and are not well suited for integration with the 
outside world. 

[0266] To expose the functionality of the Qualification 
features of the Applicants system to the outside world, the 
JavaBeans encapsulation of the GHR CORBA Server's API 
is further abstracted to facilitate clients via the HTTP 
protocol. A Java enabled HTTP server is positioned to 
intercept function calls via the outside world and pass them 
into the JavaBeans which in turn make their normal CORBA 
requests to the GHR CORBA Server. 
[0267] Referring now to 34, with reference to the descrip- 
tions above, this Applicants-GHR Systems communications 
interface is defined in functional overview. An HTTP server 
receives inputs from applicants' system, wherein requests 
for data are processed and an instantiation of a GHR client 
JavaBean occurs based on type of qualification desired 
3503. These GHR JavaBeans provide an API into the GHR 
CORBA Server using distributed computing data marshal- 
ling over the Internet Inter-ORB Protocol (HOP) 3505. The 
HOP request is transmitted to a GHR CORBA server 3509 
where the data from the client JavaBeans are accepted, 
unmarshalled and used to trigger the instantiation of the 
GIIR Systems COM objects. The GIIR system using its 
COM objects, processes the request and returns qualified 
loan programs (if any). These data are formatted into an 
XML data stream and sent back to the client JavaBean. 3511. 
The Applicants system code receiving the XML datastream, 
parses the datastream and creates an HTML document for 
return to the calling web browser for end-used interaction. 
[0268] In an alternative embodiment, subprograms for 
performing the functions equivalent to those of the GHR 
system would be developed internally to applicants system. 
[0269] The 'Originator Task Menu and Origination Fee 
Assessment' Function 

[0270] As indicated above, upon completion of the loan 
selection and formal loan request, the loan originator is 
given the screen shown in FIG. 28A and is asked to specify 
the loan origination fee and to choose the functions in steps 
3, 4 and 5 which the loan originator will do. The 'Originator 
Task Menu and Origination Fee Assessment' function 519 in 
FIG. 5 uses these selections as well as the other non-selected 
required tasks to construct the inputs which are passed to the 
Compliance Engine as described above. 
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[0271] The 'Loan Fulfillment Workflow Process' 

[0272] The composite of information which is passed to 
the 'Loan Fulfillment Workflow Engjne'545 in FIG. 5 as a 
new 'context' or data embodiment, and by which a new, 
discrete, mortgage process is created comprises the summa- 
tion of data or information supplied by the 'Compliance 
Engine'520, the list of tasks related to the specific loan as 
described above. In a preferred embodiment, the list of tasks 
for the specific loan arc delivered by the Compliance Engine 
to the Loan Fulfillment System (462 in FIG. 4C) which 
comprises a Loan Processing and Mortgage Workflow 
Engine such as Framework, Inc.'s Lendware™ product. In 
an alternate embodiment the 'Loan Fulfillment Workflow 
Engine'545 in FIG. 5 is contained within applicants' system 
and would be built around the Sun Microsystems™ Inc. 
Forte™ Conductor™ engine product to manage and control 
the related business processes and to provide a runtime shell 
to facilitate coordination of application services within the 
business process. The various business applications related 
to the steps to be processed in completing the mortgage loan 
closing are pre-defined to the Forte Conductor system Oust 
as they are in the Lendware product) so that when the 
'mortgage functions' and their designated 'actionees' (if 
any) are passed to the 'Loan Fulfillment Workflow Engine' 
and to its Forte Conductor engine, these 'functions' are 
executed in an integrated environment where both the func- 
tion process definition and each of the supporting applica- 
tions is pre-defined and will execute automatically. The 
supporting applications are a set of application proxies, each 
representing the business service provided by its application 
and the pre-defined actions to take are contained in an XSL 
rule base, consisting of rule documents. Specific rule docu- 
ments are assigned to proxies so they can interpret and 
transform messages The 'Loan Fulfillment Workflow 
Engine'545 and its Forte Conductor engine assures that 
processes happen in the correct sequence and in accordance 
with the (software controlled) pre-determined, program- 
matic branching conditions defined by the 'Worker Profile 
Attributes'543 business process definition. The 'Loan Ful- 
fillment Workflow Engine'545 may call upon any combina- 
tion of 'workers', heretofore described as computers, data 
tables, software, persons, organizations, companies, or other 
data sources, etc. to perform the required tasks. The 'worker' 
or 'agent' is typically manifested in one or more of the 
following ways: as an individual, an organization, one or 
more data tables, a data processing system, or the like. 

[0273] In this alternative embodiment the pre-pro- 
grammed functional steps executed by the Forte Conductor 
system are shown in FIG. 6. The types of activities repre- 
sented by the icons on FIG. 6 include the following; 



Icon Description 

Opening door Beginning of a new process, in this case a new loan 

Closing door Ending of a process 

Computer Automated activity that does not require human 

Alarm Clock Timer activity which initiates the next activity based on 
passage of time 



[0274] The process definition drawing shown in FIG. 6 
defines the process activities for the Applicants.com com- 
pliance workflow system. By performing the defined activi- 
ties under the strict control of the Conductor workflow 
engine, the engine ensures that all required tasks are com- 
pleted, and in the required sequence. The engine presents 
activities only to workers whose role designations match the 
role designations of the activity. The earlier system activities 
assigns roles in advance to workers only after verifying that 
the pre-requisite qualifications are satisfied. In this fashion, 
loan originators are assured that all applicable pre-qualifi- 
cations are satisfied and that they actually performed all the 
services for which they were compensated. When a loan 
process is initiated in the workflow system a call is made to 
the Forte Conductor software to instantiate a new loan 
workflow process for the specific loan, as indicated by the 
parameters passed in the calling sequence. 

[0275] 'litis workflow process is better understood with 
reference to FIG. 6. Referring now to FIG. 6 , the loan 
originator 601 gathers credit data, gets authorization and 
requests puU credit 603. The automated system 607 pulls 
credit 609, processes the credit report, parses FfCO, public 
records and liabilities 611, and the credit profile is saved to 
the Oracle™ data base 612. If this credit clearing process 
exceeds 15 minutes a timeout occurs 615 and a message is 
sent to the user indicating a failure in the credit processing. 
When the credit profile is completed and saved to the 
Oracle™ data base 612 and the loan originator 601 has 
completed the loan wizard and Express app via the website 
604 the system then begins the underwriting assessment 
617. If the FICO previously determined in step 611 is not 
less than 620 the process driver submits the request to 
automated underwriting 621. If it is approved 623 the system 
generates task fists and compliance documents (GFE, TIL, 
Disclosures, etc.) 625 and submits them, to the loan origi- 
nator 627, to the premium broker processor 649, to the 
premium broker account executive 651, for their individual 
completion of their respective tasks to complete the loan 
process. The loan originator 627, the premium broker pro- 
cessor 649, and the premium broker account executive 651, 
all electronically submit a task completion message to the 
system 631 and it compares the submissions against autho- 
rization criteria 633. If the criteria are met the system 
determines whether the user has requested that the loan rate 
be locked 635 and if so the loan is loeked-in with the 
investor 661 and a message is passed to the clear-to-close 
auditor 665, 659 where a determination is made as to 
whether the transaction is clear-to-close 667. If so a message 
is passed to the closer 669 to close the loan 677. A message 
is then passed to the funder/shipper 671 to fund/ship the 
loan. The funder/shipper 671 does two things: first it verifies 
the investor purchase of the loan 683 and notifies the 
controller 675 to update the general ledger that funds have 
been received 689 and tells the end transaction mechanism 
691; secondly the funder/shipper 671 tells the controller 675 
to update the General Ledger to disburse the funds 687 
which submits a requisition to payroll 685 who notifies the 
end transaction mechanism 691. 

[0276] The system has capabilities to determine that the 
required criteria have not been mel/compleled 633 and 
determine whether to resubmit the loan request to automated 
underwriting 639, 640 or to notify the underwriter 641 to 
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iterate on the credentials review process 643 and either deny 
645, 647 the loan or approve it 645, 623 and generate the 
task lists again 625. 

[0277] Thus the loan process in this alternate embodiment 
is driven through the required tasks by the Forte Conductor 
engine to assist in the complying with the various regula- 
tions and yet automate the process in a helpful and efficient 
manner. In the preferred embodiment the ASP system Lend- 
Ware or its equivalent drives the loan process and the 
individual task workers in a manner similar to that described 
above. In the preferred embodiment the task completion data 
is passed to the Compliance Engine which monitors the list 
of tasks for each loan and which can also communicate 
directly with some task workers when certain critical events 
occur or timeouts are perceived. 

[0278] The 'Task List Maintenance and Status Reporting 
Gateway" 

[0279] The 'Task List Maintenance and Status Reporting 
Gateway"550 in FIG. 5 or 463 in FIG. 4C serves as a portal 
to communicate to and from other agents and workers who 
are qualified to perform assigned taste. These taste are those 
which would be assigned by the 'Loan Fulfillment Workflow 
Engine'545 or by the ASP workflow processor Lendware 
463 to other agents or workers to complete prior to the 
closing of the loan and distribution of funds. While this 
gateway is similar to the 'loan origination gateway' it is 
significantly different in that the middleware layer must 
handle the conversion of data format and protocol of the 
Forte Conductor engine or the Lendware workflow engine to 
and from the formats and protocols of the agents/workers to 
which the workflow process is communicating. Accordingly, 
The 'Task List Maintenance and Status Reporting Gate- 
way'550 in FIG. 5 is used to transmit messages from the 
workflow engine to these other agents and to receive 
responses from authenticated agents. These agents would be 
performing tasks such as 'title search', 'survey', 'credit 
check', etc. The 'Task List Maintenance API and Status 
Reporting Gateway'550 can also use the same interface 
modes as envisioned for The 'Loan Origination Gate- 
way'505. Envisioned are at least, three (3) ways by which 
the system may access and be accessed by a loan agent/ 
worker: (1) via Internet website, (2) via custom-written 
software which connects in a data transmission-enabled 
manner to the present invention, and (3) via 'wireless' 
devices, as previously described for the 'Loan Origination 
Gateway'505. 

[0280] A loan originator or borrower may also come into 
the system via this gateway to check the status of the loan 
process, etc. As indicated below every entrant via this 
gateway must never-the-less be authenticated before entry is 
allowed. Conveyance of task lists to a loan originator and 
associated workers and reporting of borrower loan status are 
accomplished through a programmatic presentation 552 
which embodies the following: 'borrower status rcport(s)', 
'originator's task list', and 'other worker's task lists' (as 
described above) — said information exchanged through this 
'task maintenance & status reporting Gateway' (the "TMSR 
gateway"). This 'TMSR gateway', functions in a manner 
similar to that used during the loan origination process. 
Reports may be conveyed by a variety of programmatically 
controlled means, such as web pages, PDF® files, word 
processing format files, etc. The TMSR gateway receives the 



direction messages from the 'Loan Fulfillment Workflow 
Engine'553 in the standard Forte Conductor or Lendware 
API format, and using the middleware layer described 
before, converts the format and message protocol into that 
required to communicate with the desired agent/worker. 
Similarly, the TMSR gateway can receive messages from the 
various agents/workers in various formats and protocols (i.e. 
HTML, XML, WML, WAP, etc.) and converts these mes- 
sages and protocols into the standard API formats used in the 
preferred embodiment. 

[0281] Referring now to FIG. 36 the principle purpose of 
the 'TMSR Gateway'4200, in serving as a portal, is to 
provide a way for the loan originator and borrower to check 
the status of the loan process and for the 'loan process 
workflow engine' to communicate to and from the other 
agents/workers who are doing some task required by the 
process, without having to worry about what input method 
or output method is required to communicate with a given 
entity, and/or the related data formats and protocols. Con- 
sequently the major purpose of the TMSR gateway is to 
perform the middleware tasks of — recognizing the input 
channel and data format and protocol used 4209 and convert 
the data lo the standard workflow engine Application Pro- 
gramming Interface (API) format 4211 which will be used 
by the workflow engine. Similarly, on receiving a message 
to be transmitted from the workflow engine, the TMSR 
gateway middleware structure is required to determine the 
format & protocol used by the addressee and convert the 
message from the workflow engine API format into the 
format and protocol of the addressee 4215 and then transmit 
the message 4217 to the addressee 4203 or 4205 or 4207. 
The input data originates from the input screens provided by 
the system, and from the output data pre-defined in the 
various task elements in a typical loan workflow process. 
The workflow engine will typically transmit a required 
message whenever an event occurs which requires a mes- 
sage be sent or resent (because of a timeout for example). 

[0282] The TMSR gateway is required to pass the received 
data to a second authentication module 549 in FIG. 5 or 464 
in FIG. 4C. This authentication module once again verifies 
the used ID and password of the inputting user. In the 
preferred embodiment this check does not verify the legal 
qualifications of the user. In an alternative embodiment, the 
user ID is checked to determine the worker Type, and the 
roles this type worker may perform for this location of the 
properly and for his location are verified against the role he 
is attempting to play. Similarly the compliance engine 
checks to see if the various legal regulations allow this 
agent/worker to perform the role they are attempting to play. 
If so the authentication module 4212 in FIG. 36 will pass the 
data submitted to the aforementioned workflow engine 42 13 
for its processing of the incoming data in response to the task 
assigned. 

[0283] Transaction Service Provider Gateway 

[0284] Returning now to FIGS. 4C and 5, the 'Vendor 
Management API Gateway 467 in FIG. 4C or the 'Trans- 
action Service Provider Gateway'555 in FIG. 5 serves to 
manage 'tasks' assigned to external agents or workers or 
vendors with whom Applicants' have a special vendor 
relationship. That is, a vendor who supplies appraisals in a 
given locality, loan processing, credit checks, title searches, 
flood certification, mortgage insurance, etc. The 'Vendor 
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management API Gateway' or the 'Loan Fulfillment Work- 
flow Engine', (see FIG. 6 for example) in developing a task 
list for the loan originator (627 in FIG. 6), recognizes some 
tasks as falling under the responsibility of the loan originator 
as determined in the loan origination process, and some 
tasks which are to be automatically forwarded to certain 
service provider agents or vendors. The communication of 
these assignments, occurs in a different manner than those 
described above relative to the TMSR gateway. Since these 
tasks tend to be more routine and repetitively performed by 
the specific vendors, the workflow engine will send a 
message to the designated vendor and wait (i.e. maintain the 
telephonic or electronic connection) until the vendor sup- 
plies the desired response (which normally would be within 
a few minutes) or until a watchdog timer expires. If the timer 
expires the workflow engine will try the communications 
again as well as notify a system manager that the vendor has 
not responded. 

[0285] For example referring now to FIG. 36 the 'trans- 
action service provider gateway' (the "TSP gateway") 4400 
is described. The functioning of the 'Vendor Management 
API gateway' under the control of Lendware, for example, 
would function similarly. Whenever the workflow process 
for this loan 4401 recognizes an event/task which requires a 
communication to a vendor/partner (service provider), the 
workflow process constructs the message and passes it to the 
TSP gateway 4403. The TSP gateway determines the format 
and protocol required to communicate with the indicated 
service provider and translates the message from the work- 
flow process formal into the required format and protocol fur 
the service provider 4405. The TSP gateway then establishes 
a persistent communications link with the service provider 
4407 and sends the message and waits for a response 4409 
. If the service provider does not respond in a given lime a 
watchdog timer expires 4411, 4413 in which case the system 
administrator is notified 4415 and the message is resent 
4409. If the service provider responds within the allotted 
time 4423, 4425 the circuit connection is released 4427 and 
the response is translated from the format and protocol of the 
service provider into the format required by the workflow 
process 4429 and the response is passed back to the work- 
flow process 4431. 

[0286] During the course of the workflow process execu- 
tion of the various tasks as shown in FIG. 6, the workflow 
process engine records each transaction into an Oracle 
database in order lo create and maintain an audit trail of 
tasks performed for this loan, when performed, by whom, 
etc. This database is used for certain reports triggered by 
other tasks in the workflow process as well as ad-hoc reports 
of tasks completed for various compliance and maintenance 

[0287] Worker Compensation and Task Performance 
Report Module 

[0288] The 'Worker Compensation and Task Performance 
Report' Module 468 in FIG. 4C or 557 in FIG. 5, provides 
a mechanism for producing reports lo accounting lo distrib- 
ute funds to those agents/workers who have earned them in 
a particular loan transaction. These reports in a preferred 
embodiment are normally triggered by the Compliance 
Engine but may be triggered in an alternative embodiment 
by the loan workflow process for that loan at certain pre- 
defined points in the workflow. This module also provides 



the capability for generating regulatory completion reports 
and/or Completion Certificates as required for each loan. 
[0289] The 'Secondary Banking Process' Module 
[0290] The 'Secondary Banking Engine' module 469 in 
FIG, 4C or 561 in FIG. 5 serves to manage loan transactions 
as they are introduced to the secondary lending pool, and 
move them programmatically through the process of 'clos- 
ing', 'funding', and 'shipping' the loan transaction. In one 
embodiment, 469 in FIG. 4C, is managed by Lendware via 
on on-site installation or equivalently by Framework ASP. In 
an alternative embodiment, the secondary banking functions 
would be managed and processed within applicants' sys- 
tem.561 in FIG. 5. In the alternative embodiment, the 
'Secondary Banking Engine'561 would also serve as the 
mechanism whereby the transactions and finds distributions 
involving the bundling and selling of loans to the secondary 
banking institutions are verified and reported in the follow- 
ing manner: (a) 'Locked Loan reports, tracking all loans 
locked by borrowers, and reported on a regular schedule, (b) 
Commitment report, tracking all unfulfilled loan commit- 
ments, (c) Funding report, which tracks and reports initial 
funding status (d) Funded, but not Shipped report, (c) 
Shipped but not Purchased report, and (f) Purchased Loan 

[0291] In an alternative embodiment, a special task of the 
secondary banking module is to manage use of the funds in 
the warehouse credit line. The management objective is to 
optimize the financial return generated by the funds in the 
warehouse line of credit. If too much of the warehouse line 
is consumed in covering mortgage loans processed, the 
overall return on these funds is diminished. Accordingly the 
management task is to move mortgage loans from the 
warehouse line to secondary investors as quickly as pos- 
sible. This may be done by selling individual loans to 
secondary investors, or by pooling multiple loans, according 
to various credit conditions and pooling rules for sale to 
other secondary investors. 

DESCRIPTION OF THE BEST MODE 
[0292] Referring now to FIGS. 31-32 the various types of 
computer hardware and computer software used in a pre- 
ferred embodiment at the present time are depicted. In FIG. 
31 it is clear that Sun® Ultra5™ workstations 3101 and 
general purpose Personal computers (PC) 3 103 may be used 
as input devices to the system. A Sun E250™ dual processor 
server 3105 is used as a developmenl/lest system running the 
Sun® Solaris® operating environment, Oracle® 81, Forte® 
Conductor™ with a SynerJ™ server. A single processor Sun 
E250™ server 3107 is used in the Sunnyvale facility. Also 
in this facility are three Sun E4500™ dual processors 3117, 
3119 and 3121, an IBM NetFinity 7000™ quad processor 
with a Microsoft® NT™ server 3115 and a Hitachi Shared 
Disk array 3123. There are also three IBM NetFinity 5000™ 
servers 3109, 3110 and 3111 located in the Salt Lake City 

[0293] In FIG. 32 it may be seen lhat loan originators 
interface to the applicants system using a standard Internet 
browser such as Internet Explorer™3201 with the initial 
interface in applicants' system being with Lotus® 
Domino ™3203. The system Ihen performs the Pre-qualifi- 
cation and Loan application & Approval using GIIR® 
Systems PriemierWare™3209. The Sun Solaris® operating 
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environment in the system server (at 3203 in FIG. 32) 
interfaces with the GHR system 3209 and to FastDi- 
rect™3211 via HOP through a CORBAto COM bridge and 
a Delphi Automation interface to Windows NT™ . Solaris™ 
interfaces in this configuration to the Oracle 81® server via 
Forte® Conductor™3207 through Forte Enterprise Java- 
Beans, Forte Distributed JavaBeans and HOP. 
[0294] Having described the invention in terms of a pre- 
ferred embodiment, it will be recognized by those skilled in 
the art that various types of general purpose computer 
hardware may be substituted for the configuration described 
above to achieve an equivalent result. Similarly, it will be 
appreciated that arithmetic logic circuits are configured to 
perform each required means in the claims for performing 
the various features of the rules engine and flow manage- 
ment. It will be apparent to those skilled in the art that 
modifications and variations of the preferred embodiment 
are possible, such as different computer systems may be 
used, different communications media such as wireless 
communications, as well as different types of software may 
be used to perform equivalent functions, all of which fall 
within the true spirit and scope of the invention as measured 
by the following claims. 

We claim: 

1. A computer implemented method for generation of a set 
of required procedures for processing a mortgage loan using 
an Internet based system having a client loan origination 
system electronically coupled to an automatic compliance 
engine, the method comprising the acts of: 

the automatic compliance engine receiving a request to 
process a mortgage loan from the client loan origina- 
tion system; 

the automatic compliance engine generating a plurality of 
tasks, the tasks comprising actions required to process 
the mortgage loan, including tasks required by appli- 
cable federal or state law; and 

the automatic compliance engine distributing one or more 
of the tasks to the client loan origination system. 

2. The computer implemented method for automated 
processing a mortgage loan of claim 1 comprising the 
additional act of the automatic compliance engine monitor- 
ing completion of the plurality of tasks whereby a report of 
completion of all required tasks can be generated. 

3. The computer implemented method for automated 
processing of a mortgage loan of claim 1 comprising the 
additional act of the automatic compliance engine authen- 
ticating a person submitting the request to process a mort- 
gage loan. 

4. The computer implemented method for automated 
processing of a mortgage loan of claim 1 wherein the 
plurality of tasks required to process the mortgage loan are 
based upon mortgage loan related laws and regulations 
comprising Federal, State, local and professional regulations 
and requirements and implementing instructions relating to 
mortgage loan processing. 

5. The computer implemented method for automated 
processing of a mortgage loan of claim 1 wherein the client 
loan origination system communicates with the automatic 
compliance engine using an XML format according to an 
application programming interface (API) controlled by the 
automatic compliance engine. 



6. The computer implemented method for automated 
processing of a mortgage loan of claim 1 wherein the client 
loan origination system communicates with the automatic 
compliance engine using a web page developed for use with 
the automatic compliance engine. 

7. An apparatus for automated processing of a mortgage 
loan comprising: 

an automatic compliance engine having logic mecha- 
nisms programmed to generate a plurality of tasks, the 
tasks comprising actions required to process the mort- 
gage loan, including tasks required by applicable fed- 
eral or state law; 

the automatic compliance engine coupled electronically 
to a client loan application system; 

the automatic compliance engine having communications 
devices for receiving a request to process a mortgage 
loan from the client loan application system; and 

the automatic compliance engine having additional logic- 
mechanisms programmed to electronically distribute 
one or more of the tasks to the client loan application 
system. 

8. The apparatus of claim 7 further comprising electronic 
logic devices in the compliance engine programmed to 
monitor completion of the plurality of tasks and to generate 
a report of completion of all required tasks. 

9. The apparatus of claim 7 wherein the compliance 
engine communicates with the client loan application system 
using an XMI, format according to an API controlled by the 
compliance engine. 

10. The apparatus of claim 7 wherein the plurality of tasks 
generated by the compliance engine which are required to 
process the mortgage loan are based upon mortgage loan 
related laws and regulations comprising Federal, State, local 
and professional regulations and requirements and imple- 
menting instructions relating to mortgage loan processing. 

11. An apparatus for automated processing of a mortgage 
loan comprising: 

means for receiving a request to process a mortgage loan 
from a client loan application system; 

means, coupled to the means for receiving a request to 
process a mortgage loan from a client loan application 
system, for generating a plurality of tasks, the tasks 
comprising actions required to process the mortgage 
loan, including tasks required by applicable federal or 
state law; and 

means, coupled to the means for generating a plurality of 
tasks required to process the mortgage loan, for elec- 
tronically distributing one or more of the plurality of 
tasks to the client loan application system. 

12. In a network having a user node including a browser 
program coupled to said network, said user node under the 
control of a client loan application system for providing 
requests for information and providing mortgage loan appli- 
cation related commands on said network, a network node 
comprising: 

a mortgage loan processing server node responsive to a 
request from said user node to process a mortgage loan, 
whereby said mortgage loan processing server node 
provides a first mechanism for generating a plurality of 
tasks, the tasks comprising actions required to process 
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the mortgage loan, including tasks required by appli- 
cable federal or state law; and provides a second 
mechanism coupled to the first mechanism, for distrib- 
uting one or more of the plurality of tasks to the user 

13. The network node of claim 12 wherein the mortgage 
loan processing server node provides a third mechanism to 
electronically communicate with the user node using an 
XML format for an API controlled by the mortgage loan 
processing server node. 

14. The network node of claim 12 wherein the actions 
required to process the mortgage loan are based upon 
mortgage loan related laws and regulations comprising 
Federal, State, local and professional regulations and 
requirements and implementing instructions relating to loan 
processing. 

15. A computer program product stored on a computed 
useable medium, comprising; 

a first computer readable program mechanism for receiv- 
ing a request to process a mortgage loan from a client 
loan application system; 

a second computer readable program mechanism for 
generating a plurality of tasks, the plurality of tasks 



comprising actions required to process the mortgage 
loan, including tasks required by applicable federal or 
state law; and 

a third computer readable code mechanism for distribut- 
ing one or more of the plurality of tasks to the client 
loan application system. 

16. The computer program product of claim 15 compris- 
ing a fourth computer readable code mechanism for moni- 
toring completion of the plurality of tasks whereby a report 
of completion of all required tasks can be generated. 

17. The computer program product of claim 15 wherein 
the plurality of tasks required to process the mortgage loan 
are based upon loan related laws and regulations comprising 
federal, State, local and professional regulations and 
requirements and implementing instructions relating to 
mortgage loan processing. 

18. The computer program product of claim 15 wherein 
the communications with the client loan application com- 
prises messages containing data in XML format. 
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A process and a system for providing a user with a plurality 
of periodic retirement income payments is disclosed. The 
process comprises the steps of receiving an input including 
two of a retirement date, a minimum retirement income 
amount and a defined premium payment amount for pay- 
ment over a plurality of preset payment intervals. The 
process also includes the steps of calculating the other one 
of the retirement date, the minimum retirement income 
amount and the defined premium payment amount for an 
accumulation period defined by the retirement date and a 
current age of the user; receiving a premium payment 
amount from the user during the accumulation period; 
investing the received premium payment amount in an 
account in a manner consistent with one or more predefined 
objectives during the accumulation period to realize a retire- 
ment income amount. The process further includes the step 
of transmitting the retirement income amount to at least one 
of the user and a designated receiver at a designated time 
after the end of the accumulation period. The retirement 
income amount includes a predetermined guaranteed mini- 
mum retirement income if the received premium payments 
- received according to a preset premium payment sched- 
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METHOD AND SYSTEM FOR PORTABLE 
RETIREMENT INVESTMENT 

BACKGROUND OF THE INVENTION 

[0001] Up until about 1870, more than half of the United 
States' adult workers were farmers. These adult workers 
were typically engaged in Lheir occupations until Iheir death 
or until their health prevented them from continuing their 
occupations. It was uncommon to have a prolonged retire- 
ment period before a worker's death. 

[0002] After 1870, however, industry developed rapidly 
and the economy tended increasingly to be characterized by 
industrialization and urbanization. The result was that work- 
ers increasingly were employed in more industry-related 
jobs and became more dependent upon a continuing flow of 
monetary income to provide for themselves and their fami- 
lies. Additionally, the average life expectancies of workers 
began to increase significantly. It became more common for 
workers to retire from employment and to survive for longer 
periods of time following their retirements. Retirement 
programs began to take hold. The Social Security program 
was introduced in 1935 and had an old age insurance 
component which provided a lump sum benefit for workers 
at age 65. At that time, the average life expectancy of a 
worker was 68. 

[0003] Currently, however, half of male workers reaching 
age 65 can expect to still be alive at age 82 and half of 
female workers reaching age 65 can expect to be alive at age 
86. The Social Security program is not keeping pace with 
such changes. The number of employees entering Lhe work- 
force has been less than the number of new retirees for the 
last several years and this trend is expected to increase as the 
"Baby Boomers" age. The Social Security Administration 
("SSA") projects a shortfall in its trust fund which provides 
benefits to retirees beginning in 2013. The SSAbelieves that 
an immediate and permanent increase of social security 
payroll taxes is necessary in order to enable it to pay for the 
full amount of old age benefits it currently provides retirees. 
Now, employees and employers contribute approximately 
12.4 percent of salaries to the Social Security trust fund. The 
SSAprojects that contributions must be increased to at least 
38 percent in order for its trust fund to remain fully funded. 
Therefore, it is becoming increasingly uncertain whether the 
Social Security program will continue to remain viable until 
the time that today's workers are ready to retire. Moreover, 
many retirees have found that the amount of retirement 
benefits to which they are entitled under the Social Security 
program is insufficient to enable them to maintain a desired 
level of comfort in their retirement. 'JTiey have found a need 
to supplement such Social Security benefits with income 
from other sources. 

[0004] In addition to the institution of the Social Security 
program in the 1930s, beginning in the early 1900s, it 
became increasingly more common for employers to pro- 
vide their workers, or employees, with some sort of retire- 
ment benefits or pensions. These retirement benefits or 
pensions were originally designed, in part, to reward an 
employee for his/her long career with a company and to help 
provide an income once such employee retired. Such retire- 
ment benefits or pension plans therefore required minimum 
periods of employment before an employee's entitlement to 
the pension amount became vested. However, many such 



retirement benefits or pensions are not portable. In other 
words, if an employee leaves the employ of an employer, 
that employee may lose all entitlement to such retirement 
benefit or pension if the employee terminates his/her 
employment prior to the expiration of the vesting period. 
This was not a problem when employers first instituted such 
retirement benefits or pension plans as employees tended lo 
remain employed with one employer for their entire career 
until they retired. 

[0005] However, in today's mobile society, employees do 
not tend to remain employed by one employer for their entire 
careers. Many employees therefore lose some or all of their 
projected retirement benefits which may have accrued dur- 
ing their employ by their employers when they leave the 
employ of such employers. 

[0006] Furthermore, in addition to the trend of a more 
mobile society and an increased level of employment 
changes, many employers are decreasing the numbers of 
their employees and arc instead increasingly turning to 
non-employee labor in part to cut expenses resulting from 
employee benefits such as cosls related to funding employee 
retirement plans. Thus, many individuals in the workforce 
today are technically not considered "employees" but 
instead are independent contractors for whom employment 
benefits such as retirement benefits are not provided. Addi- 
tionally, many employers arc ceasing to offer defined benefit 
plans altogether because of the costs. In fact, according to 
statistics published by the Pension Benefil Guaranty Corpo- 
ration, defined benefit pension plans of employers have 
decreased by more than 60 percent since 1985," with the 
number of U.S.-based employers that offer such defined 
benefit pension plans decreasing from 114,000 in 1985 to 
less than 40,000 in 1999. Only 21.3 percent of working 
family heads are currently covered by an employer-funded 
defined retirement benefit or pension plan. 

[0007] Because of the decrease in the number of employ- 
ers that offer defined retirement benefit pension plans, the 
decrease in the number of workers entitled to employer- 
funded retirement benefits and also because of the increased 
mobility of the workforce resulting in the loss of such 
employer-funded benefits, many workers have started to 
fund their own retirement savings plans. Tax laws have 
enabled workers to realize tax benefits from deferring their 
income by putting amounts from their paychecks into such 
retirement savings plans. Increasingly, such employee-self- 
funded retirement savings plans are becoming the primary 
sources of income on which employees survive following 

[0008] However, one disadvantage of the increased reli- 
ance upon employee-self -funded retirement savings is that 
these plans do not provide a level of retirement income that 
is guaranteed for the employee. In addition, many employ- 
ees do not have any idea of an amount required to be saved 
in order to achieve a desired level of income to ensure a 
comfortable lifestyle upon their retirement. Thus, they do 
not contribute a sufficient amount of Iheir salaries towards 
such retirement savings to provide an adequate income level 
to maintain the standard of living they desire upon retire- 
ment. Based on the results of the Retirement Confidence 
Survey sponsored by lhe Employee Benefits Research Insti- 
tute (EBRI), the American Savings Education Council 
(ASEC), and Matthew Greenwald and Associates, 22 per- 
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cent of all employed adult workers have saved less than 
$10,000 towards retirement, 50 percent have saved less than 
$50,000 and only 25 percent of adult workers over the age 
of 55 have accumulated more than $100,000. 

[0009] Retirement income needs may increase in the event 
such retirees suffer from health-related problems. In fact, 
many employees today express concern that they will not 
have adequate funds saved to provide for themselves during 
their retirement in the event they suffer health-related prob- 
lems after they retire. They are currently seeking some 
means to ensure a higher level of income saved for such 

[0010] Employees often do not participate in their 
employer-sponsored retirement savings plans which will 
increase the level of their savings through interest income or 
a return on investment. Also, many individuals lack the 
sophistication needed to determine the appropriate type of 
investment vehicle which will offer them a high return on 
their investment but which is also secure enough so that their 
savings are not placed at risk by a high-risk type of invest- 
ment vehicle. 

[0011] Thus, there is a need for an investment vehicle 
which will provide a minimum retirement income which is 
portable so that a worker will not lose any income vested in 
a fully funded investment vehicle if the worker leaves the 
employ of an employer or changes jobs. 
[0012] There is also a need to provide a denned retirement 
benefit which will guarantee an individual a minimum 
defined income level upon the individual's retirement. 
[0013] Additionally, there is a need for a retirement invest- 
ment vehicle which may provide a guaranteed minimum 
level of retirement income and also may afford an individual 
an opportunity for an increase in value of the benefits 
provided if market performance of the retirement vehicle 
exceeds a predefined benchmark. 

BRIEF SUMMARY OF THE INVENTION 

[0014] The above-described problems and needs are 
addressed by the system and process of the present inven- 
tion. According to one embodiment of the invention, a 
process for providing a user with a plurality of periodic 
retirement income payments is disclosed. The process com- 
prises the steps of receiving one or more premium payments 
from the user during an accumulation period; and investing 
the received premium payments in an account in a manner 
consistent with one or more predefined objectives during the 
accumulation period and a payout period to realize a retire- 
ment income amount. The process further includes the step 
of transmitting the retirement income amount to at least one 
of the user and a designated receiver at a designated time 
after the end of the accumulation period. The retirement 
income amount includes a predetermined guaranteed mini- 
mum retirement income amount if the received premium 
payments are received according to a predetermined pre- 
mium payment schedule, wherein one of the predetermined 
guaranteed minimum retirement income amount and a pre- 
mium payment amount is defined by the user. 
[0015] In another aspect of the invention, a quoting pro- 
cess is provided. The quoting process comprises the steps of 
receiving as an input two of a retirement date, a minimum 
retirement income amount and a defined premium payment 



amount for payment at each of a plurality of preset payment 
intervals; and calculating the other one of the retirement 
date, the minimum retirement income amount and the 
defined premium payment amount, wherein the user 
receives the minimum retirement income amount when the 
user reaches the retirement date if the user pays the defined 
premium payment amount at each of the preset payment 
intervals. 

[0016] In yet another aspect, a process for providing a user 
with periodic retirement income payments is disclosed. The 
process comprises the steps of receiving an input including 
two of a retirement date, a minimum retirement income 
amount and a defined premium payment amount for pay- 
ment at each of a plurality of preset payment intervals; 
calculating the other one of the retirement date, the mini- 
mum retirement income amount and the premium payment 
amount based on the input for an accumulation period 
defined by the retirement date and a current age of the user; 
receiving a plurality of premium payments from the user 
during the accumulation period; investing the received pre- 
mium payments in an account in a manner consistent with 
one or more predefined objectives during the accumulation 
period to realize a retirement income amount; and transmit- 
ting the retirement income amount to at least one of the user 
and a designated receiver at a designated time after the end 
of the accumulation period wherein the retirement income 
amount includes a predetermined guaranteed minimum 
retirement income if the received premium payments are 
received according to a predetermined premium payment 
schedule, and wherein one of the predetermined minimum is 
retirement income amount and the premium payment 
amount is defined by the user. 

[0017] Additionally, in another aspect, a process for 
investment is disclosed. The process comprises the steps of 
receiving a premium payment amount from a user at each of 
a plurality of predefined intervals over an accumulation 
period during employment at a first employer during a first 
part of the accumulation period; receiving the premium 
payment amounts from the user during employment at a 
second employer during a second part of the accumulation 
period; investing the received premium payment amounts 
during the accumulation period; and transmitting a retire- 
ment income amount to at least one of the user and a 
designated receiver at a designated time after the end of the 
accumulation period, wherein the retirement income amount 
includes a predetermined guaranteed minimum retirement 
income if the total received premium payment amounts were 
received according to a predetermined premium payment 
schedule, and wherein one of the predetermined minimum 
retirement income amount and the premium payment 
amount is defined by the user. 

[0018] In still another aspect, the invention includes a 
quoting system. The quoting system comprises means for 
receiving as an input two of a retirement date, a minimum 
retirement income amount and a defined premium payment 
amount for payment at each of a plurality of preset payment 
intervals; and means for calculating the other one of the 
retirement date, the minimum retirement income amount 
and the defined premium payment amount, wherein the user 
recei%'es the guaranteed minimum retirement income when 
the user reaches the retirement date if the user pays the 
defined premium payment amount at each of the preset 
payment intervals. 



US 2002/0188540 Al 



3 



Dec. 12, 2002 



[0019] Additionally, in another aspect, a system for pro- 
viding a user with a plurality of periodic retirement income 
payments is disclosed. The system comprises a variable 
deferred annuity module to receive a predetermined pre- 
mium payment from the user at each of a plurality of 
predetermined payment intervals to invest the premium 
payments and to output an income generating payment; and 
a variable immediate annuity module to receive the income 
generating payment and to output a periodic retirement 
income payment amount wherein the periodic retirement 
income payment amount is greater than or equal to a 
predetermined guaranteed minimum periodic retirement 
income payment amount if the premium payments received 
are received according to a predetermined premium payment 
schedule, and wherein one of the predetermined minimum 
periodic retirement income payment amount and a premium 
payment amount is denned by the user. 
[0020] The accompanying drawings, which are incorpo- 
rated in and constitute a part of this specification, together 
with the description, serve to explain the principles of the 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0021] FIG. 1 is a block diagram illustrating a quoting 
system for a retirement benefit according to the present 
invention; 

[0022] FIG. 2 is a block diagram illustrating one embodi- 
ment of an overall system in which the quoting system of 
FIG. 1 may be implemented; 

[0023] FIG. 3 is a block diagram illustrating one embodi- 
ment of a system for providing a user with periodic retire- 
ment income payments; and 

[0024] FIG. 4 is a flow diagram illustrating one embodi- 
ment of a process for providing a user with periodic retire- 
ment income payments. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0025] Reference will now be made in detail to the present 
preferred embodiments of the invention, examples of which 
are illustrated in the accompanying drawings in which like 
reference numerals refer to corresponding elements. 
[0026] The present invention is described in relation to a 
portable retirement benefit annuity. Nonetheless, the char- 
acteristics and parameters pertaining to the systems and 
methods may be applicable to other types of annuities and 
other financial instruments. 

[0027] An annuity is a flexible tax-deferred retirement 
investment product that can provide long term earnings for 
an investor ("user"). An annuity allows a user's retirement 
savings to grow on an income tax-deferred basis and allows 
the user to choose a payout option that best meets the user's 
need for income when the user retires. Payout options may 
include a lump sum payment, a plurality of periodic pay- 
ments, income for a remainder of the user's life, or a 
plurality of income payments paid out over a certain period 
of time. The portable retirement annuity described herein 
will be an annuity providing a plurality of periodic income 
payments for the remainder of the user's life, for a period not 
less than a defined certain number of years, or for some 
combination of the two. 



[0028] When a user purchases an annuity, also known as 
a long-term investment contract, the user typically pays an 
insurer an initial sum of money (called a premium or 
principal) and the insurer invests that principal in an invest- 
ment type of financial product to earn a return on that 
principal. In return for the initial sum of money, or premium 
payment, and the use of that initial sum of money, the insurer 
guarantees the user either a steady stream of income pay- 
ments with no upside earnings potential or a stream of 
income payments adjusted for market performance (but 
generally not both) beginning at a specified date in the future 
and lasting for a specified period of time. While the premium 
payment is invested in the investment vehicle, the premium 
payment grows or compounds over time, but the user does 
not have to pay any taxes on the earnings. This phase of an 
annuity contract is referred to as an accumulation period. 
Once the user has accumulated an amount of money the user 
requires for retirement, the user can begin to receive periodic 
income payments made from the accumulated investment 
premium. Only when the user begins to receive income 
payments are the moneys subject to taxes. One disadvantage 
to a typical annuity contract, however, is that it typically has 
a date which, if the user wishes to withdraw his/her moneys 
prior to such date, the user will be penalized and will have 
to pay the insurer a surrender charge (we will refer to this 
date as the "surrender charge period date"). Additionally, if 
the user withdraws his/her money out of the annuity invest- 
ment vehicle account prior to age 59Vi years, other than as 
a series of periodic payments, the Internal Revenue Service 
also requires payment of a penalty since he/she had obtained 
the benefit of tax-deferred treatment during the time the 
moneys were invested. 

[0029] There are several standard types of annuity con- 
tracts which insurers offer. A fixed annuity is an annuity 
where the insurer guarantees the user the invested principal 
value and a payment of a fixed rate of return for a stated 
period of time on the premium payment invested during the 
accumulation period and a guaranteed income for life if the 
user "annuitizes" or converts the annuity into a stream of 
regular income payments. The insurer takes responsibility 
for investing the user's premium payment in whatever types 
of financial products it believes will earn enough income to 
enable it to meet its obligations under its guaranteed rate of 
return to the user. Assuming that the user holds the annuity 
contract until after the surrender charge period date, the 
benefit of such a fixed annuity contract to the user is in 
having a guaranteed income payment stream over a long 
period of time. 'Hie user is essentially betting that he/she will 
live a longer period of time than expected and will therefore 
realize a substantially higher amount of money in the 
guaranteed income payments than the initial premium pay- 
ment. On the other hand, the insurer is betting on the 
opposite scenario, i.e., that it can make favorable invest- 
ments of the premium payments which result in increased 
earnings and that the users, as a class, will not live longer 
than expected. 

[0030] Fixed deferred annuities are popular because of 
their safe and predictable rates of return. Insurers often place 
fixed annuity contract premium payments into bonds or 
other conservative types of investment vehicles. Since fixed 
deferred annuities guarantee a specific return on the initial 
investment and a guaranteed return of principal, they are 
attractive to potential investors when the equity stock market 
is under-performing and interest rates are on the rise. How- 
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ever, under fixed deferred annuity contracts, the user is 
generally not advised of and does not participate in the 
insurer's investment choices and thus has to trust the insurer 
to make wise investment decisions. Moreover, under recent 
economic conditions, fixed deferred annuities have not been 
a popular choice as users have preferred to participate in the 
equity slock markets with the expectation of a higher rate of 
return on investment, but with the full knowledge that their 
principal may be at risk. 

[0031] Variable deferred annuities have become more 
popular in recent years. With a variable deferred annuity 
contract, the user can decide how his/her premium payment 
will be allocated among a specific menu of investment 
vehicles, or sub-accounts, offered by the insurer. Sub-ac- 
counts are pooled investments of a number of users, similar 
to mutual funds, with varying investment objectives and 
strategies and typically have a professional fund manager 
similar to managers of mutual funds. The manager of the 
sub-account will decide where to invest the pooled funds 
based upon the objectives of the particular sub-account, e.g., 
growth, emerging industries, bonds, etc. The accumulated 
moneys in the annuity account of the user fluctuate with 
market values and with the user's choice of sub-accounts. 
[0032] Variable deferred annuities have advantages over 
fixed deferred annuities since they enable the user to direct 
how his/her premium payment will be invested among one 
or more sub-accounts. Moreover, variable deferred annuities 
could potentially enable the user to earn more money on the 
initial investment than he/she could with a fixed deterred 
annuity contract if the user selected strong sub-accounts 
with high rates of return on investment. However, the 
variable deferred annuity contract makes no guarantees to 
the user regarding the amounts earned on the premium 
invested, the value of invested principal or the income 
amount to be paid out after the accumulation period, so the 
user could also potentially end up earning less money than 
desired if the sub-accounts selected by the user arc weak or 
perform poorly. Since the value of the variable deferred 
annuity is tied to the risks inherent in the stock market, a 
downturn in the stock market could cause the value of the 
variable deferred annuity to drop. Thus, variable deferred 
annuities are not desirable to those users who are risk averse. 
[0033] There are also fixed immediate annuity contracts. 
Purchasing a fixed immediate annuity requires a lump sum 
premium payment. The amount of retirement income is 
determined at the time of purchase and the retirement 
income can be paid out over the life of the user, over a 
certain period of time, or over a combination of the two. 
Retirees often purchase a fixed immediate annuity with 
funds they receive from 401(k) plans, Individual Retirement 
Accounts ("IRAs"), savings account funds, the cash value or 
death proceeds from a life insurance policy or proceeds from 
the sale of a home. The insurer issuing the fixed immediate 
annuity guarantees payments directly to a user on a monthly, 
quarterly, semi-annual or annual basis for the life of the user, 
for a certain period of time, or for some combination of the 
two. At the time of purchase, the income payments are 
locked based upon current market interest rates. The user's 
income payments are determined by, among other things, a 
combination of the market interest rate, the payment options 
selected by the user, the premium payment amount and the 
life expectancy of the user. Once the lump sum premium 
payment is made, the user has exchanged the lump sum 



premium payment for a series of guaranteed payments that 
will not change as a result of market performance. With a 
fixed immediate annuity, the user does not have any input 
concerning how the lump sum premium payment is 
invested. 

[0034] A variable immediate annuity, like a fixed imme- 
diate annuity, guarantees income over the life of the user, for 
a certain period of time, or for a combination of the two. 
However, unlike a fixed immediate annuity where the 
income payments are fixed and do not vary, the income 
payments received from the variable immediate annuity vary 
based on market performance. The user could potentially 
earn more or less on a variable immediate annuity because 
of the equity investments. 

[0035] In one embodiment of a process according to the 
present invention, an insurer is able to combine favorable 
features of each of the above-described annuities into a 
single retirement annuity product, i.e., a guaranteed payment 
stream in a manner similar to a fixed immediate annuity; a 
guaranteed retirement income amount in a manner similar to 
a fixed immediate annuity; an upside potential for a return on 
investment during the accumulation period in a manner 
similar to a variable deferred annuity; and a potential to 
realize an increased retirement income amount based on 
equity market performance in a manner similar to a variable 
immediate annuity. 

[0036] In another embodiment, pursuant to a risk mitiga- 
tion process of the present invention, an insurer may offer a 
guaranteed m in imum retirement income amount to a user by 
eliminating the inherent economic uncertainties associated 
with traditional deferred and immediate annuities. By hav- 
ing the user predetermine before purchase of a retirement 
annuity product a desired retirement date and a predictable 
premium payment amount and a schedule of premium 
payments, the insurer is able to lower the cost to the user of 
the guaranteed minimum retirement income amount. 
[0037] FIG. 1 is a block diagram illustrating one embodi- 
ment of a quoting system 10 for retirement benefits accord- 
ing to the present invention. The quoting system 10 may 
include a quote calculator 2, an input module 1 and an output 
module 3. The input module 1 and the output module 3 are 
shown for illustrative purposes only. In one embodiment, 
either the input module 1 or the output module 3, or both, 
may be a part of the quote calculator 2. The quoting system 
10 may be used to provide a quote to a user on one or more 
parameters relating to a purchase or a contract for a retire- 
ment annuity product. 

[0038] The input module 1 may receive information input 
by a user or an agent on behalf of a user regarding the user 
and one or more retirement desires of the user. In one 
embodiment, the input information may include two of a 
retirement date, a minimum retirement income amount the 
user would like to receive, or a defined premium payment 
amount the user would like to make towards the user's 
minimum retirement income amount. In one embodiment, 
the input information may include a retirement dale, a 
minimum retirement income amount, a premium payment 
amount, a current age of the user, a gender of the user, and 
an indication of whether a retirement annuity will be a joint 
retirement annuity (i.e., based on two lives) or a single 
retirement annuity (i.e., based on one life). Additionally, in 
one embodiment, the input information may include an 
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indication of whether the user would like to add one or more 
riders to the retirement annuity contract and/or the type of 
rider(s) to be added. The riders available to the user may 
include a disability rider, an unemployment rider and an 
early death rider as described below with reference to FIG. 
3. 

[0039] In one embodiment, an agent or a software pro- 
gram may help the user to determine the retirement date, the 
minimum retirement income amount the user would like to 
receive or the defined premium payment amount the user 
would like to make. In one embodiment, the input module 1 
may represent a screen of a software program or a web page. 

[0040] The quote calculator 2 may include hardware and/ 
or software to calculate retirement account information. 
Given two of the user's retirement date, the minimum 
retirement income amount or the defined premium payment 
amount as inputs, the output module 3 may calculate the 
other one of the retirement date, a premium payment amount 
required to meet the user's minimum retirement income 
amount or the retirement income amount that would be paid 
to the user based on the defined premium payment amount 
the user would like to make, depending on the one not input 
by the user to the input module 1. For example, if the user 
chooses to input the user's retirement date and the desired 
minimum retirement income amount, the output of the quote 
calculator 2 would be the required premium payment 
amount to achieve the minimum retirement income amount. 
If the user chooses to input the retirement date and the 
desired premium payment amount, the output of quote 
calculator 2 would be the minimum retirement income 
amount available to the user based on the denned premium 
payment amounts the user would like to make. However, if 
the user chooses to input the desired premium payment 

output of the quote calculator 2 would be the user's retire- 
ment date. 

[0041] In one embodiment, the output of the quote calcu- 
lator 2 may include a retirement annuity contract. In one 
embodiment, the user may be presented with a quote for the 
purchase of a proposed retirement annuity contract including 
terms meeting the parameters input by the user. The quote 
may be presented to the user as a web page or another similar 
type of user interface. 

[0042] In one embodiment, the quote calculator 2 may 
base the premium payment amount quote or the minimum 
retirement income amount quote on an annuity accumulation 
period defined by the user's retirement date and the date of 
the quote. In one embodiment, the quote for the minimum 
retirement income amount will guarantee thai the user is 
paid the minimum retirement income if the user pays the 
premium payment amount at each of a plurality of prede- 
termined payment intervals, for example, a plurality of 
monthly payment intervals. In one embodiment, the pre- 
mium payment amount or the minimum retirement income 
amount may be calculated by using at least one equity 
performance factor such as a stock index. Additionally, the 
minimum retirement income amount may be varied depend- 
ing on a sales channel pursuant to which a sale of an annuity 
contract is made. For example, if the sale of the annuity 
contract was made direct to a consumer (e.g., via an Internet 
web site) without an agent, an insurer offering such annuity 
contract can pass its distribution savings realized by virtue 



of not having to deal with the agent onto the consumer in the 
form of a higher guaranteed minimum retirement income. 
[0043] In one embodiment, the output module 3 may also 
output a cost breakdown including a retirement income 
amount, a disability income rider charge, an unemployment 
income rider charge, an early death rider charge, a lump sum 
equivalent, an interest rate lock period and a buy-down 
option where the user can buy-down the premium payment 
amount incrementally. In one embodiment, if the user has a 
choice of either a paid-up option or a partially paid-up option 
for the early death rider, the output module 3 may output a 
quote including each of these options. In another embodi- 
ment, the user may input a choice of a type of early death 
rider and the output module 3 may output only a cost of the 
type of early death rider chosen by the user. 

[0044] In one embodiment, the user may input information 
in a software program or a web page, including a name, an 
address, a Social Security or tax ID number, a beneficiary, a 
qualified/nonqualified pension plan, and a 1035 Exchange 
replacement (i.e., referring to a tax-free exchange pursuant 
to Section 1035 of the Internal Revenue Code). An output of 
the quote calculator 2 may include a signature ready appli- 
cation for purchase of the quoted annuity product. The 
signature ready application may be an electronic signature 
ready application that may either be printed out and signed 
or affixed with an electronic signature and submitted over a 
network, such as the Internet. The output may also include 
a pre-autborized check approval form pursuant to which a 
bank or financial institution may automatically withdraw the 
premium payment amount from the user's account for 
payment of the premium payment amounts when due. The 
output may further include a transmittal sheet for transmittal 
of the completed electronic application to a broker/dealer. 
[0045] In one embodiment, the retirement income amount 
or annuity payment may be a joint annuity payment, for 
example, for a legally married couple. In one embodiment, 
a minimum retirement income amount may be guaranteed 
for either a single lifetime period or a joint lifetime period. 
In another embodiment, the minimum retirement income 
amount may be guaranteed for a single lifetime period or a 
joint lifetime period with a predetermined certain period for 
the annuity payments. The predetermined certain period 
may be measured from a date at which annuity payments or 
transmission of the retirement income to the user begins. For 
example, the predetermined certain period may be a ten year 
certain period where, if the user of the annuity dies before 
the end of the predetermined certain period, a beneficiary 
designated by the user will receive the annuity payment until 
the end of the predetermined certain period. 
[0046] In one embodiment, a minimum retirement income 
amount or the defined premium payment amount may be 
dependent upon both a mortality rate and an interest rate. In 
one embodiment, the minimum retirement income amount 
will be guaranteed independent of the user's employer. 
Thus, the minimum retirement income amount described 
herein is fully portable if the user changes employers. 
[0047] FIG, 2 is a block diagram illustrating one embodi- 
ment of a network 200 in which the quoting system 10 of 
FIG. 1 may be implemented. In this embodiment, the 
quoting system 10 may be available to a plurality of users 21 
through a network 23, which may be the Internet. The 
system 200 may include a company site 20, an internet 
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service provider (ISP) 22 and the users 21. The users 21 may 
communicate with the company site 20 through the network 
23. The users 21 may be connected to the network 23 
through the ISP 22. In one embodiment, the users 21 may be 
coupled to the ISP 22 through a communications link 27. In 
another embodiment, a user 21 may be coupled directly to 
the ISP 22. 

[0048] The communications links 23 and 27 may be 
comprised of, or may interface to any one or more of, the 
Internet, an intranet, a Personal Area Network (PAN), a 
Local Area Network (LAN), a Wide Area Network (WAN), 
a Metropolitan Area Network (MAN), a storage area net- 
work (SAN), a frame relay connection, an Advanced Intel- 
ligent Network (AIN) connection, a synchronous optical 
network (SONET) connection, a digital Tl, T3, El or E3 
line, a Digital Data Service (DDS) connection, a Digital 
Subscriber Line (DSL) connection, an Ethernet connection, 
an Integrated Services Digital Network (ISDN) line, a 
dial-up port such as a V.90, a V.34 or a V.34bis analog 
modem connection, a cable modem, an Asynchronous 
Transfer Mode (ATM) connection, a Fiber Distributed Data 
Interface (FDDI) connection, or a Copper Distributed Data 
Interface (CDDI) connection. The communications links 23 
and 27 may also include or interface to any one or more of 
a Wireless Application Protocol (WAP) link, a General 
Packet Radio Service (GPRS) link, a Global System for 
Mobile Communication (GSM) link, a Code Division Mul- 
tiple Access (CDMA) link or a Time Division Multiple 
Access (TDMA) link such as a cellular phone channel, a 
Global Positioning System (GPS) link, a cellular digital 
packet data (CDPD) link, a Research in Motion, Limited 
(RIM) duplex paging type device, a Bluetooth radio link, or 
an IEEE 802.11 -based radio frequency link. The communi- 
cations links 23 and 27 may further include or interface to 
any one or more of an RS-232 serial connection, an IEEE- 
1394 (Firewire) connection, a Fibre Channel connection, an 
infrared (IrDA) port, a Small Computer Systems Interface 
(SCSI) connection, a Universal Serial Bus (USB) connec- 
tion or another wired or wireless, digital or analog interface 
or connection. 

[0049] Although only three users 21 are shown in FIG. 2, 
in actual practice, there may be fewer or significantly more 
users 21 connected to the system 200 than shown. Additional 
users 21 may be connected through the same ISP 22 shown 
or through other ISPs 22. However, for purposes of illus- 
tration, the discussion will assume the three users 21 con- 
nected to the network 23 through the two ISPs 22. 

[0050] Although any network may be used for the system 
200, for the purpose of illustration, the users 21 and the 
company site 20 may to be connected to the Internet 23. The 
users 21 may be connected to the ISPs 22 through client 
computer systems having resident therein at least one user 
interface (UI) application module. In one embodiment, the 
UI application module may include an internet browser, 
such as a Netscape Navigator™ browser or a Microsoft 
Internet Explorer™ browser. The users 21 may further 
include an email communication application module, such 
as a Microsoft Beyond Mail™ application, a Netscape 
Mail™ application, a Eudora Pro™ application or the like. 

[0051] The users 21 may be comprised of a personal 
computer running a Microsoft Windows™ 95 operating 
system, a Microsoft Windows 98 operating system, a Mil- 



lenium™ operating system, a Microsoft Windows NT™ 
operating system, a Microsoft Windows 2000 operating 
system, a Microsoft Windows™ CE™ operating system, a 
PalmOS™ operating system, a Unix operating system, a 
Linux operating system, a Solaris™ operating system, an 
OS/2™ operating system, a BeOS™ operating system, a 
MacOS™ operating system, or another similar operating 
system or platform. The users 21 may also include a 
microprocessor such as an Intel x86-based device, a 
Motorola 68K device, a PowerPC™ device, a MIPS device, 
a Hewlett-Packard Precision™ device, a Digital Equipment 
Corporation Alpha™ RISC processor, a microcontroller or 
another general or special purpose device operating under 
programmed control. The users 21 may further include an 
electronic memory such as a random access memory 
(RAM), an electronically programmable read only memory 
(EPROM), a storage such as a hard drive, a compact disk 
read only memory (CDROM), a rewritable CDROM or 
another magnetic, optical or other storage medium, and 
other associated components connected over an electronic 
bus, as will be appreciated by persons skilled in the art. The 
users 21 may also include a network-enabled appliance such 
as a WebTV™ unit, a radio-enabled Palm™ Pilot or similar 
unit, a set-top box, a networkable game-playing console 
such as a Sony Playstation™ console or a Sega Dreamcast™ 
console, a browser-equipped cellular telephone, or another 
TCP/IP client or other device. 

[0052] 'llie users 21 may represent client systems used by 
customers or users, or agents of the company site 20. The 
company site 20 may include the quoting system 10, a server 
25 and a database 26. The quoting system 10 may be the 
quoting system 10 of FTG. I. 

[0053] The server 25 may include a workstation running 
the Microsoft Windows™ NT™ operating system, the 
Microsoft Windows™ 2000 operating system, the Unix 
operating system, the Linux operating system, a Xenix 
operating system, an IBM AIX™ operating system, a 
Hewlett-Packard UX™ operating system, a Novell Net- 
ware™ operating system, a Sun Microsystems Solaris™ 
operating system, the OS/2™ operating system, a BeOS™ 
operating system, an Apache operating system, an Open- 
Step™ operating system or another operating system or 
platform. 

[0054] Although the database 26 is shown to be outside of 
the company site 20, the database 26 may reside within the 
company site 20 in one embodiment. The database 26 may 
include or interface to an Oracle™ relational database such 
as that sold commercially by Oracle Corporation. Other 
databases, such as an Informix™ database, a Database 2 
(DB2) database, a Sybase database, an On Line Analytical 
Processing (OLAP) query format database, a Standard 
Query Language (SQL) format database, a storage area 
network (SAN), a Microsoft Access™ database or another 
similar data storage device, query format, platform or 
resource may be used. 

[0055] The database 26 may be used to store one or more 
algorithms used to calculate the quote for the premium 
payment amount or the retirement income amount requested 
by the user 21. The database 26 may also store one or more 
tables, charts, investment information, information needed 
to generate web pages, and any other data needed to generate 
the quote described with reference to the output module 3 of 
FIG. 1. 



US 2002/0188540 Al 



7 



Dec. 12, 2002 



[0056] FIG. 3 is a block diagram illustrating one embodi- 
ment of a portable guaranteed annuity system 30 for pro- 
viding a user with a plurality of periodic retirement income 
payments. In one embodiment, the portable guaranteed 
annuity system 30 may include a variable deferred annuity 
("VDA") module 32 and a variable immediate annuity 
("VIA") module 34. One or more premium payments 
received into the system 30 may be placed into the variable 
deferred annuity module 32. 

[0057] As explained above, a variable annuity is a contract 
in which the premiums paid are invested in one or more 
stock and bond sub-accounts. A variable annuity account 
value reflects the performance of the investment funds 
selected. Over the long-term, premiums invested in equity 
stock funds generally reflect the growth and performance of 
the economy and can serve as a hedge against inflation. A 
deferred annuity contract is generally one in which one or 
more annuity payouts begin at a future date. An immediate 
annuity contract is generally one in which annuity payouts 
begin immediately or within one year. Thus, a variable 
deferred annuity is generally a variable annuity in which the 
annuity payouts begin at a future date and a variable 
immediate annuity is generally a variable annuity in which 
the annuity payouts begin immediately. 
[0058] In one embodiment, the premium payments may be 
received periodically where the period is defined by an 
annuity contract. For example, the annuity contract may 
define a monthly periodic premium payment. In one 
embodiment, the user's contractual monthly premium pay- 
ment may be paid into a variable deferred annuity account 
through an electronic funds transfer. In another embodiment, 
the user may be billed on a periodic basis for the contractual 
premium payment amount. 

[0059] In one embodiment, the contractual monthly pre- 
mium payment may be deposited into a predetermined 
sub-account 38 of the variable deferred annuity module 32. 
The predetermined sub-account 38 may mirror a pension 
fund management style. At completion of a contractual 
accumulation period, the monetary value invested in the 
predetermined sub-account 38 may be transferred to the 
variable immediate annuity module 34 for payout to the user. 
[0060] If the amount accumulated in the predetermined 
sub-account 38 is greater than an amount needed for a 
guaranteed minimum retirement income amount, the com- 
pany 20 and the user 21 share the excess earnings. Thus, the 
user 21 may receive an amount greater than the guaranteed 
minimum retirement income amount during the annuity 
period. If the amount accumulated in the sub-account 38 is 
less than the amount required to achieve the guaranteed 
minimum retirement income amount, the company 20 will 
pay the user 21 an amount equal to the guaranteed minimum 
retirement income amount. 

[0061] In one embodiment, the user 21 may choose one or 
more riders for inclusion in the annuity contract such as a 
disability rider, an unemployment rider or an early death 
rider. Thus, the system 30 may include a riders module 33 
to receive a portion of the contractual monthly premium 
payment to cover any selected riders. In one embodiment, 
the riders may be administered by a reinsurance entity 35. In 
one embodiment, if the user 21 elects to include a disability 
rider in the annuity contract, the user 21 will be obligated to 
make one or more scheduled monthly rider premium pay- 



ments for a predetermined period in order that the premium 
payments will be made from another source in the event of 
a disability period. If the user 21 elects to include an 
unemployment rider, the user will be obligated to make one 
or more scheduled rider premium payments for a predeter- 
mined period to ensure that the premium payments will be 
made from another source in the event the user has an 
unemployment period. The rider premium payments cannot 
be transferred or withdrawn from the flexible premium 
funding account or from the sub-account. The rider premium 
payments must be paid from another source. 
[0062] The period of premium payments for cither of the 
disability rider and the unemployment rider may depend on 
the user's age and the user's age at disability or unemploy- 
ment. In one embodiment, there may be an elimination 
period, such as, for example, 90 days before payments may 
begin. An appropriate rider or another provision may, there- 
fore, be required in order that the premium payments will 
continue during the elimination period. Payments missed 
during the elimination period may either have a grace period 
charge paid by the rider or such a grace period charge may 
be waived pursuant to the terms of the annuity contract. The 
premium payments may vary based on at least one of a 
plurality of factors including an age of the user, a gender of 
the user, a length of time of the accumulation period, an 
occupation of the user, and a scheduled premium payment 
amount. 

[0063] In one embodiment, the early death rider for annu- 
ity contracts with joint owners will pay the remaining 
monthly premium payments in the event one of the joint 
owners dies before an annuity payment start date. This is a 
decreasing term insurance rider that may be issued as a 
single life annuity contract or a joint life annuity contract. 
[0064] In one embodiment, the user 21 may choose to pay 
a single premium which fulfills the total premium payments 
to be paid over the annuity contractual accumulation period. 
In this embodiment, the single premium may be deposited 
into a flexible premium funding account in a flexible pre- 
mium funding account module 36. In this embodiment, 
money from the flexible premium funding account may be 
transferred to the user's variable deferred annuity account in 
the variable deferred annuity module 32 periodically accord- 
ing to the user's annuity contract. For example, if the user 
has a contract requiring monthly premium payments, the 
user's entire monthly premium payment may be transferred 
to the user's variable deferred annuity account at each of the 
preset payment intervals. 

[0065] In one embodiment, the user 21 may choose to pay 
the defined premium payment amounts at the preset payment 
intervals through electronic funds transfer. In another 
embodiment, the user 21 may choose to pay the defined 
premium payment amounts at the preset payment intervals 
via manual check and may incur a monthly billing charge. 
[0066] In one embodiment, each user's flexible premium 
funding account may be used to buy-down an amount of the 
user's monthly premium payment. In this embodiment, the 
same amount will be transferred from the user's flexible 
premium funding account to the user's variable deferred 
annuity account every month until the end of the user's 
contractual accumulation period. Thus, if the user's monthly 
premium payment amount is $1,000 and the user's flexible 
premium funding account is used to contribute $300 per 
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month towards payment of that $1,000 monthly premium 
payment, the user will pay $700 a month in addition to the 
$300 amount contributed from the user's flexible premium 
funding account. In this embodiment, the company 20 may 
notify the user 21 when the user 21 must make new 
arrangements to make the monthly premium payments. In 
another embodiment, the user 21 may make more than one 
single premium payment to the user's annuity account. In 
such embodiment, each single premium payment made by 
the user 21 will be put into a separate user account in the 
flexible premium funding account module 36. 
[0067] In one embodiment, if the user 21 misses a pre- 
mium payment and the premium payments are not paid with 
interest within a predetermined time period, the user may 
forfeit the contract guarantee of the retirement annuity 

[0068] In one embodiment, premium payments allocated 
to be paid from the user's flexible premium funding account 
may be transferred monthly from the user's flexible pre- 
mium funding account to the user's variable deferred annu- 
ity account based on a predetermined formula for allocation. 
[0069] In one embodiment, the user 21 may choose to be 
released early from the annuity contract. In such embodi- 
ment, the system 30 may include a surrender charge module 
37. The surrender charge module 37 may deduct a surrender 
charge from a cash value amount of the user's VDA in the 
variable deferred annuity module 32. Hie surrender charge 
may be based upon the length of the annuity contractual 
accumulation period and a time period remaining left in the 
contractual accumulation period at a date when the user 21 
requests to be released early from the annuity contract. 
[0070] In one embodiment, if the user 21 has a flexible 
premium funding account at the time the user 21 requests to 
be released early from the annuity contract, a market com- 
mutation value of the amount in the user's flexible premium 
funding account will be transmitted to the user 21. In one 
embodiment, a surrender charge may first be deducted from 
the market commutation amount in the user's flexible pre- 
mium funding account. In another embodiment, the market 
commutation value of the user's flexible premium funding 
account will not be subject to any surrender charge. 
[0071] In one embodiment, the user 21 may be allowed to 
withdraw funds from the user's retirement annuity account. 
In one embodiment, if withdrawals made from the user's 
annuity account arc not repaid within a predetermined time 
period, the user's retirement annuity contract may forfeit the 
contract guarantee. In another embodiment, the withdrawal 
payments may be subject to surrender charges. 
[0072] In one embodiment, if the user has a flexible 
premium funding account, the withdrawals will first be 
taken from the sub-account. In another embodiment, if the 
user has a flexible premium funding account. In some cases, 
withdrawals of this typo may be subject to a commutation 
charge. Withdrawals coming from the user's flexible pre- 
mium funding accounts may be taken out on a first-in 
first-out basis, according to one embodiment. 
[0073] FIG. 4 is a flow diagram illustrating one embodi- 
ment of a process 400 for providing a user 21 with a plurality 
of periodic retirement income payments. At step 401, the 
user 21 may input a desired premium payment amount and 
a minimum retirement income amount in a portable guar- 
anteed annuity system 30. 



[0074] At step 402, the system 30 receives a premium 
payment from the user 21. In one embodiment, the step 402 
of receiving the premium payment from the user may 
include a step of receiving a monthly premium payment 
from the user 21. In one embodiment, the premium pay- 
ments received from the user 21 may include a premium tax, 
such as, for example, state-specific charges. In another 
embodiment, the received premium payment may include a 
monthly billing charge for billing the user 21. In yet another 
embodiment, the premium payments received from the user 
21 may include premium payments associated with riders. 
At step 403, the system 30 invests the received premium 
payment. 

[0075] At step 404, the system 30 may transmit the 
accumulated retirement income to the user 21. In one 
embodiment, the step 404 of transmission of the retirement 
income may include a step of placing at least a portion of the 
user's account value accumulated in the variable deferred 
annuity module 32 into the variable immediate annuity 
module 34. 

[0076] The step 404 of transmission of the accumulated 
retirement income to the user 21 may begin at a user-defined 
annuity payment start date. In one embodiment, the annuity 
payment start date may be required to be al least ten years 
after an annuity contract start date. Until then, the premium 
payments remain invested in a variable deferred annuity. 
The form of the variable immediate annuity once payments 
begin and parameters relating to the user 21 upon which it 
is based must be determined at the contract start date. In one 
embodiment, the form of the VIA may not be changed. In 
another embodiment, the form of the VIA may be changed 
but the user 21 may forfeit the contract guarantee. 
[0077] In one embodiment, the form of the VIA may be 
changed in relation to legal marriages and qualified domestic 
relation orders (QDROs) relating to the user. These changes 
may include 1) a single user/annuitant may be allowed to 
add a spouse to the VIA if the marriage occurs after the 
contract start date, in which case the benefit may be recal- 
culated; and 2) if the spousal joint owner/annuitants get 
divorced after issue and the contract is split by a QDRO, the 
company may split the contract into two single contracts 
proportionally (benefits, premiums and contract values). 
[0078] While the foregoing description includes many 
details and specificities, it is to be understood that these have 
been included for purposes of explanation only, and are not 
to be interpreted as limitations of the present invention. 
Many modifications to the embodiments described above 
can be made without departing from the spirit and scope of 
the invention, as is intended to be encompassed by the 
following claims and their legal equivalents. 

What is claimed is: 

1. A quoting process comprising the steps of: 

receiving as an input two of a retirement date, a minimum 
retirement income amount and a defined premium 
payment amount for payment at each of a plurality of 
preset payment intervals; and 

calculating the other one of the retirement date, the 
minimum retirement income amount, and the defined 
premium payment amount, wherein the user receives 
the minimum retirement income amount when the user 
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reaches the retirement date if the user pays the defined 
premium payment amount at each of the preset pay- 
ment intervals. 

2. The quoting process of claim 1 wherein a total of the 
preset payment intervals is based on a difference between the 
retirement date and a current age of the user. 

3. The quoting process of claim 1 wherein each of the 
preset payment intervals is a month. 

4. The quoting process of claim 1 wherein the step of 
calculating the other of the minimum retirement income 
amount and the defined premium payment amount is based 
on at least one of a table of mortality rates and a predeter- 

5. The process of claim 1 further comprising the step of 
presenting the user with a signature-ready application for 
electronic transmittal. 

6. The process of claim 1 further comprising the step of 
presenting the user with an application including the 
received input and the calculated minimum retirement 
income amount or the calculated defined premium payment 
amount. 

7. A process for providing a user with a plurality of 
periodic retirement income payments comprising the steps 
of: 

receiving one or more premium payments from the user 
during an accumulation period; 

investing the received premium payments in an account in 
a manner consistent with one or more predefined objec- 
tives during the accumulation period and a payment 
payout period to realize a retirement income amount; 

transmitting the retirement income amount to at least one 
of the user and a designated receiver at a designated 
time after the end of the accumulation period, wherein 
the retirement income amount includes a predeter- 
mined guaranteed minimum retirement income amount 
if the received premium payments are received accord- 
ing to a predetermined premium payment schedule, and 
wherein one of the predetermined guaranteed minimum 
retirement income amount and a premium payment 
amount is defined by the user. 

8. The process of claim 7 wherein the retirement income 
amount is an amount greater than the predetermined guar- 
anteed minimum retirement income amount. 

9. The process of claim 7 wherein the step of receiving the 
premium payments includes the step of receiving the pre- 
mium payments in a plurality of predefined interval pay- 
ments during the accumulation period. 

10. The process of claim 9 wherein the step of receiving 
the premium payments in the plurality of predefined interval 
payments includes the step of receiving a plurality of 
monthly payments during the accumulation period. 

11. The process of claim 9 wherein the step of receiving 
the premium payments in the plurality of predefined interval 
payments includes the step of receiving a late payment 
within a grace period after an interval payment was due. 

12. The process of claim 11 wherein the step of receiving 
the late payment within the grace period includes the step of 
receiving the late payment along with an interest payment 
for the time between when the interval payment was due and 
the time when the late payment is received wherein the 
interest payment is calculated based on a predefined interest 
rate. 

13. The process of claim 12 wherein the step of receiving 
the premium payments includes the step of receiving at least 



a portion of one of the premium payments in an amount 
greater than a predefined interval payment and converting 
the portion of the one of the premium payments into the 
predefined interval payment. 

14. The process of claim 13 wherein the step of converting 
the portion of the premium payments includes the stop of 
placing the portion of the premium payments in a flexible 
premium funding account and transferring a predefined 
interval payment to the account after each predefined inter- 
val until the flexible premium funding account is empty. 

15. The process of claim 13 wherein the step of converting 
the portion of the premium payments includes the step of 
placing the portion of the premium payments in a flexible 
premium funding account and transferring a predefined 
portion of the predefined interval payment to the account 
after each predefined interval until the end of the accumu- 
lation period. 

16. The process of claim 7 wherein the step of receiving 
the premium payments includes the step of receiving the 
premium payments from the user during employment at a 
first employer during at least a part of the accumulation 

17. The process of claim 7 wherein the step of receiving 
the premium payments includes the step of receiving the 
premium payments from an insurance policy in a 1035 
tax-free exchange. 

18. llie process of claim 16 wherein the step of receiving 
the premium payments includes the step of receiving the 
premium payments from the user during employment at a 
second employer during at least a part of the accumulation 
period in which the user is not employed at the first 
employer. 

19. The process of claim 7 wherein the user comprises two 
individuals, each premium payment comprises a joint pre- 
mium payment, the predetermined guaranteed minimum 
retirement income amount comprises a joint guaranteed 
minimum retirement income amount and the retirement 
income amount comprises a joint retirement income amount. 

20. The process of claim 19 further comprising the step of 
dividing the premium payment, the predetermined guaran- 
teed minimum retirement income amount and the retirement 
income amount proportionally wherein each of the two 
individuals is assigned a proportionally split premium pay- 
ment, a proportionally split predetermined guaranteed mini- 
mum retirement income amount and a proportionally split 
predetermined retirement income amount. 

21 . The process of claim 20 further comprising the step of 
adding a second user after receiving at least a portion of the 
premium payments to create a joint premium payment 
amount, a joint guaranteed minimum retirement income 
amount and a joint retirement income amount shared by both 
individuals. 

22. The process of claim 7 wherein the step of transmit- 
ting the retirement income amount includes the step of 
transmitting the retirement income amount for a period 
encompassing at least one of a life of the user and a certain 
time period. 

23. The process of claim 7 further comprising the step of 
transmitting a commuted value of at least a portion of the 
received premium payments and an invested premium pay- 
ment to the user before the end of the accumulation period 
in response to a request by the user, wherein the commuted 
value is adjusted to include a discounting impact of an 
investment return on the invested premium payment and an 
appropriate predetermined surrender charge. 

24. The process of claim 23 wherein the step of receiving 
the premium payments further comprises the steps of receiv- 
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ing a rider selection from the user and calculating the other 
of the predetermined guaranteed minimum retirement 
income amount and the premium payment based on the 
user's rider selection. 

25. The process of claim 24 wherein the step of receiving 
the rider selection includes the step of receiving a selection 
of at least one of a disability rider, an unemployment rider 
and an early death rider. 

26. Aprocess for providing a user with periodic retirement 
income payments comprising the steps of: 

receiving an input including two of a retirement date, a 
minimum retirement income amount and a defined 
premium payment amount for payment at each of a 
plurality of preset payment intervals; 

calculating the other one of the retirement date, the 
minimum retirement income amount and the premium 
payment amount based on the input for an accumula- 
tion period denned by the retirement date and a current 
age of the user; 

receiving a plurality of premium payments from the user 
during the accumulation period; 

investing the received premium payments in an account in 
a manner consistent with one or more predefined objec- 
tives during the accumulation period to realize a retire- 
ment income amount; and 

transmitting the retirement income amount to at least one 
of the user and a designated receiver at a designated 
time after the end of the accumulation period wherein 
the retirement income amount includes a predeter- 
mined guaranteed minimum retirement income if the 
received premium payments are received according to 
a predetermined premium payment schedule, and 
wherein one of the predetermined minimum retirement 
income amount and the premium payment amount is 
defined by the user. 

27. The process of claim 26 wherein the step of calcu- 
lating the premium payment amount includes the step of 
calculating the premium payment amount using at least one 
equity performance factor. 

28. A process for investment comprising the steps of: 
receiving a premium payment amount from a user at each 

of a plurality of predefined intervals over an accumu- 
lation period during employment at a first employer 
during a first part of the accumulation period; 

receiving the premium payment amounts from the user 
during employment at a second employer during a 
second part of the accumulation period; 

investing the received premium payment amounts during 
the accumulation period; and 

transmitting a retirement income amount to at least one of 
the user and a designated receiver at a designated time 
after the end of the accumulation period, wherein the 
retirement income amount includes a predetermined 
guaranteed minimum retirement income amount if the 
total received premium payment amounts were 
received according to a predetermined premium pay- 
ment schedule, and wherein one of the predetermined 
guaranteed minimum retirement income amount and 
the premium payment amount is defined by the user. 



29. A quoting system comprising: 

means for receiving as an input two of a retirement date, 
a minimum retirement income amount and a defined 
premium payment amount for payment at each of a 
plurality of preset payment intervals; and 

means for calculating the other one of the retirement date, 
the minimum retirement income amount and the 
defined premium payment amount, wherein the user 
receives the guaranteed minimum retirement income 
when the user reaches the retirement date if the user 
pays the defined premium payment amount at each of 
the preset payment intervals. 

30. The quoting system of claim 29 wherein the means for 
calculating the other of the minimum retirement income 
amount and the premium payment amount is based on at 
least one of a mortality rate and a predetermined interest 

31. The quoting system of claim 29 further comprising 
means for presenting the user with a signature-ready appli- 
cation for electronic transmittal. 

32. The quoting system of claim 29 further comprising 
means for presenting the user with an application including 
the received input and the calculated guaranteed minimum 
retirement income amount or the calculated premium pay- 
ment amount. 

33. A system for providing a user with a plurality of 
periodic retirement income payments comprising: 

a variable deferred annuity module to receive a predeter- 
mined premium payment from the user at each of a 
plurality of predetermined payment intervals to invest 
the premium payments and to output an income gen- 
erating payment; and 

a variable immediate annuity module to receive the 
income generating payment and to output a periodic 
retirement income payment amount wherein the peri- 
odic retirement income payment amount is greater than 
or equal to a predetermined guaranteed minimum peri- 
odic retirement income payment amount if the pre- 
mium payments received are received according to a 
predetermined premium payment schedule, and 
wherein one of the predetermined minimum periodic 
retirement income payment amount and a premium 
payment amount is defined by the user. 

34. The system of claim 33 further comprising a flexible 
premium funding account module means to invest a received 
premium payment into a user flexible premium funding 
account and to output one of a predetermined premium 
payment and a portion of a predetermined premium payment 
to the variable deferred annuity module, 

35. The system of claim 33 further comprising a surrender 
charge module to receive as a surrender input at least one of 
a cash value of the invested premium payments from the 
variable deferred annuity module and a market commutation 
value or an assignment value of the flexible premium 
funding account from the flexible premium funding account 
module, to add an appropriate surrender charge to the 
surrender input and to output a cash surrender amount to the 
user in response to the received surrender input. 
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(57) ABSTRACT 
A method and apparatus for automatically distributing, 
recording, monitoring, and rc-crcating communications to 
participants of an employee benefit plan, via the Internet or 
automated application. The method and apparatus include a 
server having a database containing proprietary plan and 
plan participant information. Apian sponsor or administrator 
identifies a plurality of plan rules associated with the plan 
and plan participant information, and defines a plurality of 
event triggers associated with the plan rules. The method 
and apparatus searches for event triggers based upon the 
plan rules, which are pre-configured into the system. The 
event triggers are associated with specific plan communica- 
tions medium. In an instance where an event trigger is 
initiated the method identifies a particular plan communi- 
cations medium for viewing by the plan participants, and 
determines a plan participant recipient listing to receive the 
plan communications medium. The plan communication 
medium is automatically provided to client computers' of 
the listed plan participants via a communications network. 
The listed participants must access the communications 
network and confirm having viewed the plan communica- 
tions medium prior to accessing any other attributes of the 
plan. Where a Ested participant fails to confirm viewing the 
plan communications medium over the communications 
network, a hard copy is automatically sent. The invention 
permits the plan sponsor to execute its fiduciary obligation 
to ensure delivery and communication of all relevant 
employee benefit plan documents without human interven- 
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METHOD AND APPARATUS FOR DISTRIBUTING 
DOCUMENTS ON AN EVENT-TRIGGERED BASIS 
THROUGH A COMMUNICATIONS NETWORK 
SYSTEM 

CROSS REFERENCE TO RELATED 
APPLICATIONS 
[0001] This application claims benefit of U.S. Provisional 
Application No. 60/200,840, filed May 1, 2000. 

BACKGROUND OF THE DISCLOSURE 
[0002] 1. Field of the Invention 

[0003] The invention relates to document delivery, report- 
ing, re-creation, and monitoring systems related to employee 
benefit plans and human resource (HR) programs such as 
retirement, health and welfare, stock, fringe, cafeteria, ori- 
entation, employment, executive compensation, and the like. 
In particular, the invention relates to a method and apparatus 
for delivering, reporting, re-creating, and monitoring docu- 
ments, for use by the employer, employee, and/or plan 
service provider, for such plans on an event -triggered basis 
through an internet-based and/or automated system, which is 
further consistent and in compliance with federal and state 
laws and regulations regarding the fiduciary and adminis- 
trative obligation with respect to electronic communication, 
delivery, reporting, re-creation, and monitoring of docu- 
ments as they relate to employee benefit plans. 
[0004] 2. Description of the Background Art 
[0005] Most employers (private, public sector, tax-ex- 
empt, union, and the like) offer retirement and other benefit 
plans and HR programs that are regulated by federal and 
state governments. The regulations generally require a plan 
sponsor to provide certain government agencies, as well as 
plan participants, timely reports and other documentation 
regarding plans. A sponsor's failure to deliver, report, track, 
store, monitor, and re-create plan documents or communi- 
cations can be a breach of the sponsor's fiduciary duty, 
thereby subjecting that sponsor to adverse and costly legal 
exposure from employees, as well as legal and audit expo- 
sure from the IRS and other agencies of both federal and 
state government. 

[0006] Presently, most of the record keeping and form 
generation process is performed using a manual system 
where forms and documents are self -identified (i.e., a human 
must know that an event has occurred that requires a 
federally mandated document) and then manually generated 
and printed on a periodic basis. The documents are then 
delivered to designated recipients using regular mail, hand, 
or interoffice delivery. Plan sponsors annually pay billions of 
dollars annually for iterative manual systems. 
[0007] Therefore, a need exists in the art for an automated 
document preparation, delivery, reporting, and monitoring 
system that has the intelligence to identify in one instant, an 
event that has occurred with respect to a particular employee 
benefit plan, a particular employee who must receive a 
particular document, and a particular manner and time for 
document delivery. In addition, there is a need in the art for 
the ability to provide a historical and searchable paperless 
"paper trail" of the artificial intelligence that was used to 
transact and fulfill the aforementioned system. Furthermore, 
a need exists in the art for a system to fulfill the fiduciary, 



administrative, and federal requirement to timely deliver 
documents to plan participants and other entities in a secure 
manner. Moreover, a need exists in the art for a system that 
can store and re-create any such delivered, reported, and 
monitored document for the employer, employee, and any 
service provider to the plan. 

SUMMARY OF THE INVENTION 
[0008] The invention provides a method and apparatus for 
providing timely generation and transmission, reporting, 
monitoring, re-creation of documents using an event-trig- 
gered, Internet or automated-based system (e.g., Intranet, 
local and wide area networks (LAN/WAN)), such that the 
system is compliant with all federal, fiduciary, and admin- 
istrative mandates imposed on an employee benefit sponsor. 
One embodiment of the invention is a system that complies 
with reporting and disclosure requirements for employee 
benefit plans, e.g., ERISA IRS, other federal law and state 
reporting and disclosure requirements and electronic com- 
munications regulations, as they relate to employee benefit 
plans. The system is advantageous over the prior art since it 
offers simplified compliance with federal and state rules 
(through an artificial intelligence that can identify a particu- 
lar event that has occurred with respect to a particular 
employee benefit plan, and a particular employee who must 
receive a particular document and in what manner and 
when). Furthermore, the system has the ability to provide a 
historical and searchable paperless "paper trail" of 
employer, employee, and plan service provider activity. As 
such, human error is virtually eliminated; audit/legal expo- 
sure is lessened and expenses are controlled; potential 
penalties assessed by a federal court or government agency 
for non-compliance can be avoided; HR professionals are 
freed up to focus on other critical business tasks; upwardly 
spiraling printing, delivering, and document storage costs 
are contained; and employee morale and satisfaction is 
improved. 

[0009] More specifically, the system uses a "tickler file" 
structure to generate triggering events that ensure timely 
generation, reporting, monitoring, delivery, and re-creation 
of documents and notices to plan participants and govern- 
ment agencies, all in compliance with federal, regulatory, 
fiduciary, and administrative mandates. The system uses a 
tickler file generation module to prepare tickler files com- 
prising a datc/timc/cvcnt indicator, recipient, a document 
designator, and the like. Upon a date/time/event occurring, 
the system prepares electronic mail (e-mail) to a designated 
recipient and provides a link to a Web-hosted application. A 
Web-based interface requires confirmation that the notified 
participant has read selectively linked web pages prior to 
further interaction with the system. The participant must 
confirm receipt of any forced delivered document. Once the 
system has confirmed that a delivered communication has 
been read, the user is free to retrieve documents, enter 
information, update information, signature verification, and 
the like from the system web site. That is, the participant is 
required to acknowledge, through electronic signature, the 
forced delivered documents before availing himself of any 
other attributes of the system. 

[0010] The system rounds out, and ensure compliance 
with the employer's federal fiduciary and administrative 
obligations to ensure delivery to a plan participant (e.g., an 
employee). Specifically, the system recognizes that a par- 
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ticipant has not ever linked to and viewed forced delivered 
communications (e.g., the participant has deleted the 
e-mailed link, ignored the message, and/or never accessed 
the Web). In such instance, the system uses a pre-configured 
cut-off date to notify I1R that a particular participant has not 
read a necessary document, and subsequently the system, 
without prompting, converts the document that should have 
been read into a hard copy and delivers that document to the 
participant. The system, in one embodiment of the invention, 
is simply the outsourced technology of in-house benefit plan 
administration and federal compliance work. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] The teachings of the present invention can be 
readily understood by considering the following detailed 
description in conjunction with the accompanying drawings, 
in which: 

[0012] FIG. 1 depicts a high level block diagram of the 
system of the present invention; 

[0013] FIG. 2 depicts a block diagram of one embodiment 
of the system software of the present invention; 
[0014] FIG. 3 depicts a tickler file format; 

[0015] FIG . 4 depicts a table providing various categories 
and subcategories of illustrative communications that are 
enabled by the present invention; 

[0016] FIGS. 5A and 5B together depict a flow diagram 
of an event-triggering process for transmitting documents; 
[0017] FIGS. 6A and 6B together depict a flow diagram 
of a document request and delivery process; 

[0018] FIG. 7 depicts a block diagram of a hierarchical 
plan structure of the present invention; 

[0019] FIG. 8 depicts a block diagram of a hierarchy for 
a participant structure of the hierarchical plan structure of 
FIG. 7; and 

[0020] FIG. 9 depicts a block diagram of a hierarchy for 
an administrative structure of the hierarchical plan structure 
of FIG. 7. 

[0021] To facilitate understanding, identical reference 
numerals have been used, where possible, to designate 
identical elements that are common to the figures. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0022] One embodiment of the invention permits 
employee benefit plan sponsors to deliver, report, monitor, 
re-create, and track federally mandated and routine plan 
communications through a cost-effective web-hosted and/or 
automated application, from the perspective of the 
employee, employer, and plan service provider. The system 
also forms a human resource department's repository for all 
federal and stale imposed, as well as routine plan commu- 
nications (creating a necessary historical plan document and 
employee database). Further, employees can self-service 
their employee benefit plan and personnel information 
through electronic means: on a 24-hour basis, 7 days a week, 
365 days a year. The system has the intelligence to provide 
the following: 



[0023] For a Plan Sponsor: 

[0024] Automated identification of occurrence of life or 
other triggering event; identification of affected employee; 
identification of pertinent document; and timely electronic 
(or hard copy in the event of non-electronic use) delivery of 
documents; daily and tabulated status of read/delivered plan 
communications; tracking of employee activity; permanent 
records that can be instantly queried, retrieved, and re- 
created; timely distribution of plan amendments; audit/ 
litigation protection and support; and ability to provide 
multilingual plans, documents, and other communications. 
[0025] For a Plan Administrator: 

[0026] Automated delivery of communications, upon 
occurrence of life, plant, or other triggering event; daily 
tabulated status of read and/or delivered plan communica- 
tions; permanent records that can be queried and retrieved 
online; timely distribution of plan amendments; audit/liti- 
gation support by maintaining strict audit trails of participant 
activities; quicker benefits enrollment and update capabili- 
ties; and reduced number of questions from plan partici- 

[0027] For a Plan Participant (e.g., Employee): 

[0028] Personal File Cabinet provides instant access to 
current and historical plan documents and other communi- 
cations; on-site and on-line self-service capabilities; retire- 
ment savings modeling, with Web links to the plan invest- 
ment manager; quicker and efficient access to HR personnel. 
[0029] The invention assists employee benefit plan spon- 
sors with the automated delivery of all federal and state- 
mandated documents, as well as routine plan communica- 
tions through an illustrative web-hosted application. The 
system uses a configurable tickler file intelligence for deliv- 
ering those mandated documents and communications in a 
timely manner, via the Internet. 

[0030] The invention is illustrated as a web-hosted solu- 
tion with its primary function to assist with the automated 
delivery, reporting, rc-crcation, and monitoring of all federal 
and state-mandated documents as well as routine plan com- 
munications that almost 100 percent of the nation's 
employee benefit plan sponsors currently hand deliver, 
manually record, and physically store. The system has the 
capabilities to index, retain, preserve, retrieve, and repro- 
duce electronic records (e.g., by employee, date, type of 
plan, communication, and the like), and the system sur- 
passes the government's minimum standards relating to 
electronic communication with respect to employee benefit 
plans. Ihe system can function as a stand-alone system or on 
a plan sponsor's existing information technology (IT) infra- 
structure. Although the system is illustratively described as 
a web-hosted application system, the system may also be 
implemented on any communication network such as an 
Intranet, local and/or wide area networks (LAN/WAN), and 
the like. 

[0031] FIG. 1 depicts a high-level block diagram of 
document delivery system 100 in accordance with the 
present invention. The system 100 comprises a server 102, 
the Internet 104, employee computers 106, government 
agency computers 108, and other computers or network 
appliances 110. The server comprises a central processing 
unit 114, memory 116, and support circuits 118. The support 
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circuits 118 include well-known computer circuits such as 
clocks, cache, input/output circuits, network interface cards, 
and the like. The memory 116 may include random access 
memory, read only memory, removable memory, disk stor- 
age, and the like. The memory 116 stores the software 120 
that causes the server 102 to operate in accordance with the 
present invention. The server 102 operates as a general 
purpose server until the CPU 114 executes the software 120 
to create a specific purpose server that performs document 
distribution and other user notification functions of the 
present invention. The information that is distributed by the 
system is generally provided by an information source 1 12 
that contains a database of forms, notices, documents, an 
employee record database, and events pre-programmed and 
configured by Employee Benefits Coasultants who have 
queried the plan sponsors, plans, and programs. The opera- 
tion of the system 100 is described in detail below. 

[0032] The network that interconnects the computers 106, 
108, 110 and the server 102 is shown as the Internet 104, but 
may be any form of communications network capable of 
propagating documents to particular addresses. Moreover, a 
user may access the Internet 104, illustratively from a 
remote hand held device or a home computer, via wireless 
communications, a modem, or any other communication 
medium providing Internet access to view documents and 
use the self-service features. 

[0033] The system software 120 is organized into three 
major components, each of which is distributed to a different 
place or places in the system network. A first layer is a user 
presentation layer, which supports graphical user interface 
(GUI) and application-specific entry forms or interactive 
windows. The user presentation layer is located for example, 
on the plan participant's client based computer 106 or hand 
held device. The second layer is a business logic layer, 
which provides the sets of business rules that the system 100 
follows to implement the plan. The business logic layer is 
located on the server 102 and contains the plan rules and 
defined triggers to manage document distribution to plan 
participants. Furthermore, the business logic layer acts as the 
server for client requests and determines what data is 
needed, where the data is located, and acts as a client in 
relation to programming that is located on a different data 
source. The third layer is a database access layer, which 
includes the database and programs to manage access to the 

[0034] As described in detail herein, aspects of the pre- 
ferred embodiment pertain to specific method steps, which 
may be implemented on computer systems. In an alternative 
embodiment, the invention may be implemented as a com- 
puter program-product for use with a computer system. The 
programs of the program-product define the functions of the 
preferred embodiment and may be delivered to a computer 
via a variety of signal-bearing media, which include, but are 
not limited to, (a) information permanently stored on non- 
writable storage media (e.g., read-only memory devices 
within a computer such as CD-ROM disks readable by 
CD-ROM drive); (b) alterable information stored on writ- 
able storage media (e.g., floppy disks within diskette drive 
or hard-disk drive 114); or (c) information conveyed to a 
computer by a communications medium, such as through a 
computer or telephone network, including wireless commu- 
nications. Such signal-bearing media, when carrying com- 



puter-readable instructions that direct the functions of the 
present invention, represent alternative embodiments of the 
present invention. 

[0035] FIG. 2 depicts a block diagram of one embodiment 
of the system software 120 of the present invention. The 
system software 120 includes a benefit plan database 202 
having plan information 204, plan participant information 
206, and plan communications medium 208. The plan 
information 204 comprises plan rules 210, which are asso- 
ciated with a trigger event database 222 having a plurality of 
"tickler files"224 p (see also I'IG. 3). The plan participant 
information 206 includes data for each plan participant, such 
as name, address, date-of-birth, social security number, 
years of service, job description, beneficiaries, and any other 
pertinent fact necessary for participating in the plan. The 
plan communications medium 208 include documents 214, 
plan forms 216, notifications 218, and other communica- 
tions 220 deemed pertinent to the plan. The plan commu- 
nications medium 208 arc automatically delivered to the 
plan participants for their review as discussed below. 
[0036] The system 100 operates on an event-triggered 
basis in response to information in the "tickler filcs"224. In 
particular, the software 120 includes a "search engine", 
which utilizes a repository of the rules 210, which are plan 
specific. In particular, the rules 210 are associated with one 
or more of the event triggers, which generate and automati- 
cally deliver the plan communications medium 208 to one or 
more plan participants, administrators, and the plan sponsor 
management. 

[0037] FIG. 3 depicts a tickler file format. In particular, 
FIG. 3 depicts an illustrative structure for the tickler files 
224 within the trigger event database 222 of FIG. 2. These 
files are produced by Employee Benefit Consultants through 
interaction with a tickler file creation module. This unique 
trigger event file is created only after examining specific 
parameters for each employee benefit plan stored in the 
system. The trigger event database 222 comprises a plurality 
of file entries for each tickler file 224 2 through 224 p . Each 
file entry comprises an entry identification (ID) 306 P (e.g., a 
chronological tag created by the system), a trigger descrip- 
tion 308 (e.g., an employee's hiring date), an associated plan 
communications medium 310 such as document or notice 
identifier (e.g., an employee's enrollment form into a 401 (k) 
plan), trigger criteria 312 (e.g., after three months from date 
of hire), and a trigger type 314 (e.g., immediate or daily). 
[0038] Two types of triggers are implemented by the 
system 100. The first type of trigger is a "program" trigger. 
Program triggers are computer programs written and sched- 
uled to run at certain times (e.g., hourly, daily, and the like) 
to perform specific tasks. For example, a program may be 
written to determine if an employee has greater than six 
months service, by comparing the employee start date 
against the current date. If a triggering event (i.e., a business 
rule) for sending a 401 (k) enrollment form after six months 
of service is implemented into a 401(k) plan, then the 
program would automatically set up the deliver)' of the 
enrollment form to the employee. 

[0039] The second type of trigger is an "event" trigger. 
Event triggers are programs designed to launch automati- 
cally when some event (e.g., changing a value in a database 
field) has occurred so that the program can respond to it. For 
example, if an employee's home address is modified, then 
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the event of changing that field automatically "triggers" the 
program to identify whether that change is relevant with 
respect to a delivery of any document under any employee 
benefit plan or HR program. As such, the event trigger 
automatically initiates the delivery of Form W-4 because of 
the change in the employee address field. 
[0040] FIGS. 5A and 5B together depict a flow diagram 
representing the operation of one embodiment of the present 
invention in an automated notification mode. The automated 
method 500 operates on an event-triggered basis. Referring 
to 1<IG. 5A, the method starts at step 502 and proceeds to 
step 504 where a unique and proprietary database (per 
employer) containing benefit plan and plan participant infor- 
mation is stored in the server. In step 506, the plan sponsor 
and/or administrators define the proprietary plan rules asso- 
ciated with the benefit plan and plan participant information. 
Furthermore, in step 508, the plan sponsors and/or admin- 
istrators define event triggers based on the plan rules and the 
participant information. Once the plan database is defined 
with all the rules and event triggers, the benefit plan database 
is ready for operation and interaction for that specific 
employer. The uniqueness of the system is that the system is 
employer specific (i.e., capable of identifying the particulars 
associated with one employer over others). In particular, the 
system treats each employer on an individual basis based on 
each employer's respective internal policies and plan rules. 
[0041] The method 500 proceeds to step 510, where the 
server accesses a trigger event object. The trigger event 
object information is inspected to determine if any notices or 
documents are to be sent to users (e.g., government agen- 
cies, plan sponsors, employees, and the like) at this lime. In 
one embodiment, there is a nightly read of plan sponsor and 
HR databases. The method 300 searches through the data- 
bases to determine if certain events have occurred (e.g., 
someone turns age 35 thai night). 

[0042] The method 500 queries at step 512 whether a 
transmission is required (e.g., a notice regarding turning 35 
years old). If no plan communications medium (e.g., docu- 
ment, form, e-mail notification, report) are to be sent, the 
method 500 proceeds to step 514 and waits for a predefined 
period before returning to step 510. If a transmission is 
required, the method 500 launches a message transmission 
module 524. In effect, the message transmission module is 
launched on an event-triggered basis. 
[0043] The transmission module 524 constructs the plan 
communication medium that is to be delivered. The trans- 
mission module 524 begins at step 516 by accessing the 
trigger event object entry that has identified a need for 
transmission. Step 516 identifies the plan communications 
medium (e.g., document or notice) that requires traasmis- 

[0044] At step 518, the method 500 accesses the recipi- 
ents' list. Each plan communications medium is formatted to 
provide relevant information regarding cither general infor- 
mation for all the participants, or specific information for a 
particular participant. For example, communications that are 
intended for distribution to all the participants have general 
information provided in a header of the communication. 
Such general information is stored in various fields of the 
database and is copied into the body of the communications 
medium as required. Similarly, information that is specific to 
a plan participant is copied from various fields in the plan 



participant database as required, and attached to the body of 
the plan communications medium to generate a completed 
communications for delivery. 

[0045] In step 520, an electronic mail (e-mail) message is 
prepared. The e-mail includes a link to a web-hosted appli- 
cation where the plan communications medium (e.g., docu- 
ment/notice) can be viewed. At step 522, the e-mail message 
is sent to the recipients on the recipient list, and the method 
500 proceeds to step 526. 

[0046] Referring to 5B in step 526, the method 500 waits 
a predefined period of time for each recipient on the list to 
confirm that each has viewed the appropriate forced deliv- 
ered communication medium. That is, the user is invited to 
access selected web pages in the plan web site, which are 
pertinent to that particular user or participant. In step 528, a 
determination is made as to whether the user has accessed, 
acknowledge, and electronically signed an affirmation on the 
selected plan web pages. 'Hat is, if the user fails to go to 
web-hosted application after a predefined period of time, the 
system recognizes that the user has not viewed the plan 

[0047] If the determination of step 528 is answered affir- 
matively, then the method 500 proceeds to step 530, where 
the user is enabled to access the entire web site that is 
dedicated to such participant. If, however, in step 528, the 
determination is answered negatively, then the method pro- 
ceeds to step 536. 

[0048] In step 536, an alternate communication channel 
already pre-configured by the system (e.g., hard copy sent by 
mail, courier, priority mail, and the like) is used to notify the 
listed plan participant and/or provide the relevant subject 
matter (such that the employer's federal, fiduciary, and 
administrative obligations are carried out without further 
human invention). Optionally, in steps 532, a second e-mail 
may be sent to the listed recipient prior to sending the 
communication by an alternate communication channel. In 
step 534, the system monitors whether the selected web 
pages have been viewed. If, in step 534, the determination 
is answered affirmatively, then the method proceeds to step 
530, where the recipient is allowed to view participant 
related web pages. 

[0049] If, however, the determination in step 534 is 
answered negatively, then the method proceeds to step 536 
where the alternate communications channel is provided. 
Once the listed participant has either viewed a event trig- 
gered communication or related web pages, or has been sent 
a hard copy notification or document, the method 500 ends 
at step 538. 

[0050] JTie rules based trigger event system enables the 
system 100 to automatically present documents to plan 
participants. In one embodiment, the rules are employed by 
using simple Boolean algebra to determine if either a 
program or event trigger should be executed. Using the 
forgoing trigger event based system, a plan sponsor (e.g., 
employer) will meet all reporting and disclosure requirement 
deadlines in an automated manner, once those deadlines are 
pre-configured by the plan sponsors and system administra- 

[0051] Moreover, the programming of the rules is adaptive 
to for modification, due to changes in the federal and state 
laws, or other plan changes. As such, the system adminis- 
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trators are enabled to modify the rules as required. For 
example, a particular ERISA law may change, which 
requires fewer years of service for an employee to receive a 
particular benefit. The system administrators are capable of 
modifying the rule containing such years of service param- 
eter. As such, the plan participants and governmental agen- 
cies are able to receive plan documents and communications 
in a timely and cost effective manner. 

[0052] FIG. 4 depicts a table 400 providing various cat- 
egories and subcategories of illustrative communications 
that are enabled by the present invention. Table 400 illus- 
tratively includes documents/notices, recipients, types of 
plans that require such notices, and when the document/ 
notice should be sent to the recipients. The table 400 
illustratively focuses primarily on retirement plans, but the 
system 100 can support trigger-event delivered documents 
and notices for all types of employee benefit plans, and table 
400 should not be considered as limiting. 

[0053] The first column 402 lists a type of form such as an 
enrollment form, beneficiary designation form, a notification 
form, and the like. The second column 804 provides for 
whom the form pertains. For example, the enrollment form 
shown as the first entry in column 402 pertains to eligible 
employees based on age, service, classification, and the like. 
The third column 406 provides when the form is to be 
completed. For example, the enrollment form is to be 
completed before the entry date. The fourth column 408 
specifies the required fields that must be completed in the 
form. All forms and notices require participant name, par- 
ticipant social security number, employer's identification 
number (EIN) and a plan number. Each form or notice also 
includes additional fields that are specific for the particular 
form. For example, the enrollment form includes fields for 
date of birth, minimum age requirement, years of service, 
and the like. The fifth column 410 provides the types of 
plans the form or notice is applicable to. For example, the 
enrollment form is applicable to all plans, which require or 
permit employee contributions, and some that do not. The 
sixth column 412 provides administrative notes, For 
example, the enrollment form does not apply to most defined 
benefit plans or money purchase plans. 

[0054] FIGS. 6A and 6B together depict a flow diagram 
of a document request and delivery process. In particular, 
FIGS. 6A and 6B depict the operation of the system 100 in 
an interactive mode. The interactive method 600 begins at 
step 602 and proceeds to step 604, where a user receives an 
email to access a plan web site beginning with a plan home 
page. The web site comprises a user interface, which pro- 
vides a user with access to view plan information, docu- 
mentation, and communications offered and sent by the plan 
sponsor. 

[0055] The user is presented with the home page of the 
plan web site, where the user is requested to "logon" to the 
web site. Txigins arc tracked, so as to document and archive 
access, confirmation of receipt, and electronic signature. To 
ensure authorized access of the web pages, the entire web 
site or portions thereof may be password protected such that 
only authorized users may access the information available 
through the web site. Additional security is provided by 
minimizing user access rights to an as need basis, as well as 
authentication mechanisms. For example, there are different 
access levels for varying management levels at HR (from 



clerk to manager). Password expiration dates and minimum 
character length requirements may be implemented. More- 
over, repeated login errors (e.g., three consecutive login 
attempts and failures) will result in the user from further 
attempting to login and a notice to a system administrator 
and the user of the three unsuccessful login attempts. 

[0056] Providing various user classes further restricts user 
access rights. User classes include plan participants, system 
administrators, system managers, and a demonstration user. 
Plan participants are illustratively current or past enrolled 
employees who typically are the main users of the system 
100. System administrators manage the user business 
objects including the participants, plan, and communica- 
tions. System managers have access to management report- 
ing functions of the system 100, while demonstration users 
are those users who are limited to a demonstration program 
of the plan and its features. Accordingly, the user class 
system provides additional security by limiting access to 
specific features of the system 100. 

[0057] Other, various security measures may be imple- 
mented to safeguard the system and user from privacy and 
against tampering of records. In one embodiment, all Inter- 
net hypertext transport protocol (hup) data is encrypted. For 
example, the system may implement a Secure Sockets Layer 
(SSL), which is a protocol created by Netscape Corporation 
for managing the security of message transmissions over the 
Internet. One skilled in the art can envision other encrypting 
techniques to secure the transfer of information over the 
Internet. Further security measures may include user session 
timeouts after a predetermined time of inactivity, non-access 
to new users until the new user is verified by an adminis- 
trator, and the like. 

[0058] Referring to FIG. 6A, after logging in to the plan 
home page in step 604, the method 600 proceeds to step 606. 
In step 606, a communications viewer is presented to the 
participant. In step 608, the communications viewer displays 
all relevant plan documents and/or communications sent to 
the plan participant. These documents and communications 
may be relevant to a particular class of plan participants or 
to all of the employees or participants of a particular plan 
sponsor. Furthermore, the plan sponsor or the plan admin- 
istrators define the relevancy of any plan communication 
medium (e.g., document, notification, and the like) in accor- 
dance to the federal, state, and agency laws, and plan 
sponsor policies. While the communications viewer is not 
strictly a part of the site hierarchy, the communications 
viewer is utilized to allow the plan participants to retrieve 
unread documents and communications. The user of this 
inventive system 100 is prohibited from proceeding to any 
of the lower tier web pages until all of the unviewed 
documents and/or communications have been selected for 
review by the user. 

[0059] In step 610, the documents and communications 
arc listed, for example, in chronological order of delivery, 
and are identified as having been either "read" or "unread". 
In step 612, the user must select (e.g., click on a "read" 
button) each unread document or communication deemed 
relevant to satisfy the requirements of not having any unread 
documents or communications before proceeding to the 
lower tier web pages. Thai is, only those forced delivered 
documents deemed relevant by the plan sponsor must be 
read prior to proceeding to the lower tier web pages. In step 
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614, the user confirms thai the selected document or com- 
munication has been viewed. Alternately, the user may print 
or download the documents and/or communication to satisfy 
such requirement (shown in phantom in step 616). 

[0060] The method then proceeds to step 618, where the 
system determines whether any other listed documents and 
communications remain in an unread condition. If, in step 
618, the determination is answered affirmatively, then the 
method 600 proceeds to step 612, and continues through step 
618, until the determination is answered negatively. Other- 
wise, the user is logged off after some period of time and in 
step 632, an event trigger notifies a system administrator 
regarding the unread, forced delivered document. Thereaf- 
ter, in step 634 a hard copy of the notification is delivered 
manually to the participant, already pre-configured on the 
system. 

[0061] If, however, in step 618, the determination is 
answered negatively, then the method 600 proceeds to step 
620. In step 620, the user is returned to the home page and 
permitted to proceed to the lower tier web pages to view or 
search information regarding the user's plan or benefits. 
[0062] Referring to FIG. 6B, in step 620, the user may 
select from the home page a number of options such as a 
profile request, a plan request, and a document request. If the 
profile request is selected, the method 600 proceeds to step 
622 and displays a profile web page wherein a user may 
access, download, and/or modify their user profile (e.g., user 
name, address, social security number, and other personal 
identification information). If a plan request is selected, the 
method 600 proceeds to step 624. In step 624, the method 
600 displays plans web page, where a user can access, view, 
search, and/or download plan descriptions. If a document 
request is selected, the method 600 proceeds to step 626 to 
view a document web page, which provides a list of docu- 
ments that can be viewed or downloaded by the user. At step 
628, the method 600 queries whether additional selections 
are to be made. If the query is affirmatively answered, the 
method 600 proceeds to step 620; otherwise, in step 630 is 
requested to log off, and method 600 ends at step 636. 

[0063] The web pages of the present invention are 
designed to be user friendly by maximizing viewing areas 
and provide ease of navigation. The web site for each plan 
is structured in a hierarchical format beginning with a home 
page and linking, via a plurality of menus and/or hyperlinks, 
to subsystem web page views. 

[0064] Furthermore, the method 600 is provided with the 
capability to determine whether there arc any documents or 
communications that remain unread for a time exceeding 
some predetermined period due to user inactivity or failure 
to access the plan web site, 'ltie predetermined period may 
be a global standard time for all the unread messages. 
Alternately, the predetermined period may be based upon the 
user class, priority, or urgency of the document or commu- 
nication. Surpassing the predetermined period is an event 
trigger. The event trigger is programmed to automatically 
notify a plan administrator to send the plan participant a hard 
copy of the plan communications medium, for example, by 
mail or courier. Alternately, the event trigger automatically 
sends a second e-mail to the plan participant prior to 
notifying the plan administrator. If the plan participant is 
unresponsive to the second e-mail after a second predeter- 
mined period of time, then the plan administrator is notified 



of the system's automatic delivery and recordation of hard 
copy to the participant without human intervention. 
[0065] In this manner, the system 100 ensures that a user 
is automatically notified of any new plan information gen- 
erated, by utilizing the trigger event database 202 and, more 
importantly, the system ensures the employer that a feder- 
ally-mandated document is indeed delivered to the partici- 
pant, as is required by law. Moreover, where the user is 
delinquent or does not have access to the Internet, the system 
100 automatically provides hard copy documents and/or 
communications to the plan participant without any inter- 
action of a human resource administrator. 
[0066] FIG. 7 depicts a block diagram of a hierarchical 
plan structure 700 of the present invention. The hierarchical 
plan structure 700 is embodied in a plan web site of the 
present invention, which is proprietary and unique to a 
particular entity such as a corporation, governmental agency, 
or any other facility that provides one or more employee 
benefit programs for the particular entity's employees, own- 
ers, families, and the like. A particular entity's plan web site 
may be installed at the entity's facilities or hosted by a 
service provider on the illustrative system 100 as shown in 
FIG. 1. 

[0067] In one embodiment, the plan web site comprises a 
plurality of web pages, which are accessed in a hierarchical 
order for categorizing plan information. The web pages are 
written in HTML, which is displayed in a web browser 
format such as a NE'liiCAPE® browser or a MICROSOFT 
INTERNET EXPLORER® browser. The information is 
presented in various tiers beginning with general informa- 
tion at a plan home page 702 and progressively provides 
more categories and detailed information as the user 
accesses lower tiered web pages. 

[0068] The plurality of web pages are designed with the 
same format throughout the hierarchical structure, thereby 
providing consistency so that the users may become easily 
acclimated to navigating through system. For example, in 
one embodiment a plan home page 702 and respective 
lower-tier web pages 704 each comprise a header section 
712, a footer section 718, a navigation menu section 714, 
and a main contents section 716. The header section 712 is 
located on the top of the web page and is used to display the 
product and/or particular entity logo. The footer section 718 
is located on the bottom of the web page and is used to 
display optional information according to each client's pref- 
erences for the plan. The navigation menu section 714 is 
located on the left side of the page. The navigation menu 
section 714 of the home page 702 illustratively contains a 
login form having input elements for the participant's user 
name, ID number, personal identification number (PIN), 
password, help button, and the like (not shown). The main 
content section 716 displays informational or welcome 
messages concerning client-specific information and any 
other viewable content material. As such, each web page 700 
contains information concerning the current participant, 
plan, and state of a user's session. Furthermore, one skilled 
in the art may envision other embodiments of the web pages 
that provide viewing and navigational capabilities. 
[0069] Referring to FIG. 7, the hierarchical structure 
illustratively depicts the home page 702, which is a first tier 
page, and three lower tier web pages 704, which are cat- 
egorizes as second tier web pages. From the home page 702, 
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the user may select and view lower tier web pages 704, such 
as one or more administrator web pages 706, participant web 
pages 708, and a communications viewer 710, which allows 
an administrator or participant to view documents and 
notices sent by the system 100. Furthermore, when avail- 
able, links to other web pages (i.e., third tier information) 
may be optionally selected and viewed from each of the 
second tier web pages, and so on down the hierarchical 
system structure. As such, a user may navigate up and down 
the hierarchical structure to view plan information and 
notifications as required. 

[0070] FIG. 8 depicts a block diagram of a hierarchy for 
a participant structure of the hierarchical plan structure of 
FIG. 7. In particular, the participant web page 708, which is 
located in the second tier of FIG. 7, is illustratively linked 
to four third tier web pages 802 containing plan information 
from which a user may select. These third tier web pages 802 
include a participant profile web page 804, a participant plan 
web page 806, a participant enrollment web page 808, and 
a participant tools web page 810. 

[0071] The participant profile web page 804 allows a 
participating user to access web pages (e.g., fourth tier and 
progressively other lower tier web pages) associated with 
viewing and managing their currently stored plan profiles. 
The participant profile may contain information such as 
name, address, date of birth, dependent information, email 
address, contact information, and any other relevant 
employee and plan information. A main navigation menu 
allows a user to view or update their current profile, as well 
as change a personal identification number (PIN). When a 
user updates his or her profile, the system will only allow 
read access of the profile information by another user while 
the profile is being updated. During the update, the current 
profile is copied and saved. The user is presented with fields 
containing the current information, which may be modified. 
Once the profile information is modified, the user "clicks" 
on an update button to save the information to a new update 
file. In a deferred update scenario, the update file is sent to 
an administrator for review and update. In a real-time 
scenario, the previous profile information is archived and the 
new update file is sent to the storage server, which becomes 
the "new" current profile information. 

[0072] The participant plan web page 806 is an entry point 
for allowing a participant to access the web pages associated 
with displaying and managing the plans for which they are 
currently eligible, as well as any communications associated 
with each plan. A list of eligible plans associated with a 
participant (that is, only those plans relevant to the particular 
employee) is presented so that the user may "drill-down" to 
the plan's general information, communications, and 
optional external account access. The communications dis- 
played under each plan's page are only those which are 
common to the plan, are eligible for the participant to view, 
and which the participant has read or viewed using the 

[0073] The web pages associated with certain types of 
plans and communications that can be managed under the 
system 100 may include 401(k) plans, stock option plans, 
health plans, and the like. The aforementioned employee 
benefit plans are mentioned for illustrative purposes only 
and should not be considered as limiting. Additional plans 
may include pension plans, portfolio analysis, HR programs, 



or any other plan or program deemed desirable by a plan 
sponsor. Eligibility for each plan is determined on a plan- 
by-plan basis and pre-configured into the system, and each 
user must meet all eligibility requirements as defined under 
each plan in order to have access via the plan page. Plan 
communications may include static HTML communica- 
tions, such as a plan summary, summary plan description, 
plan eligibility rules, schedules, frequently asked questions; 
forms, such as enrollment, investment election, beneficiary 
designation, and the like; and template communications, 
such as letters, personalized notifications, stock option 
awards or agreements, and the like. These plan web pages 
are static HTML. As such, no server-side processing is 
required for any elements associated with the plan pages. 
[0074] The participant enrollment web page 806 allows 
the user to display, manage and enroll in various health (e.g., 
medical, dental, and vision), insurance and disability plans 
(e.g., long-term disability, flexible spending accounts), and 
any other benefit plans deemed desirable by the plan spon- 
sor, and which the user may be currently eligible. In one 
embodiment, the enrollment page 806 becomes active and 
available during a pre-defined enrollment period, and pro- 
vides a central location for the most current benefit com- 
munications and enrollment forms. Eligibility is determined 
on a benefit-by-benefit basis, and each user must meet all 
eligibility requirements as defined under each benefit in 
order to have access via the enrollment page 806. 
[0075] The participant tools 810 provide the user with a 
set of basic tools for managing their benefits and commu- 
nications. Each tool is singular in function and allows the 
user to quickly find and extract the necessary information 
from their plan or benefit documentation. In the event that 
the tools are unable to provide a definitive answer for the 
participant, the system 100 provides finks to the plan docu- 
mentation or a benefit administrator on each web page of the 
particular plan. 

[0076] The participant tools 810 include a communica- 
tions search tool and a historical archive of documents and 
communications. The communications search tool permits a 
participant to search through documents and communica- 
tions based on one or more words or phrases pertaining to a 
particular plan or benefit. A result list is generated where 
some of the results may be hyper-linked to the actual 
document or communication for in depth review. Searches 
are performed, for example, by a search engine using 
database development software such as COLD FUSION®, 
manufactured by AUair LLC, which allows for full-text 
indexing and search capability of documents and data 
sources. Such search engines are well known in the art, and 
are discussed herein for completeness. 
[0077] The historical archive allows a participant or user 
to access and isolate each historical document and commu- 
nication. A historical document or communication is one 
that has been delivered as a result of a plan event and viewed 
by the participant with the communications viewer, or one 
that is available to be viewed regardless of eligibility in the 
relevant plan or benefit such as the summary plan document. 
In addition, the archived documents are stored in the system 
to allow the plan sponsor to retrieve and re-create such 
documents upon request, to illustratively satisfy any gov- 
ernmental or agency legal requirements. 
[0078] Referring to FIG. 7, a"Personal File Cabinet" 
(PFC) 720 is optionally available on the web site for access 
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by the participants and the plan administrators, 'lhe PFC 720 
provides instant access to current and historical plan, benefit, 
and other communications. The PFC functions as a personal 
assistant, which keeps complete audit trails for documents 
based on who sent such document, who viewed the docu- 
ment, and what the document looked like. In particular, the 
PFC 720 keeps an archive of all relevant HR documents that 
have ever been issued to a participant. All documents issued 
to any given participant are automatically archived, includ- 
ing blank forms (for example, a blank Form W-4). The audit 
information contains time, date, IP address, user ID, as well 
as customized document related information. 
[0079] An administrator of the plan sponsor or employer 
controls the PFC. The plan sponsor or employer adminis- 
trator controls what is designated as a relevant document for 
archival purposes. A document marked as "archive" is kept 
in the system database and PFC permanently. A document 
non-archived marked document is stored in the system 
database only. In one embodiment, documents arc marked as 
"archive" by default. Where a non-archived marked docu- 
ment is sent, only the most recent version of such document 
is kept in the PFC. Furthermore, non-archived documents 
may be edited, such as, a health benefits request form. 
[0080] The PFC 720 includes a at least one drawer 722 t 
having at least one folders 72V Each drawer 722 is labeled 
and organized with similar documents. For example, the 
PFC 720 may have drawers 722 labeled "Health Benefits", 
"Retirement Benefits", "Other Insurance Benefits", "Other 
IIR Notices", and the like. The folders 724 represent a 
subcategory for documents in each drawer 722. As such, the 
participant is presented with an organized history of all 
relevant communications that were sent to such participant. 
[0081] While the participant web sites 708 provide static 
HTML web pages for delivering and tracking the processing 
of a communication, the administrator web pages 706 pro- 
vide a dynamic interface for managing the plans, benefits, 
and communications associated with each plan or benefit in 
the system 100. As such, a human resource or third-party 
administrator is able to manage the parameters associated 
with each plan event related to document delivery and 
produce pre-defined or ad hoc reports based on these events. 
[0082] FIG. 9 depicts a block diagram of a hierarchy for 
an administrative structure of the hierarchical plan structure 
of FIG. 7. In particular, the administrator web page 706 are 
located in the second tier of FIG. 7, and are secured with 
administrator login procedures, password protection, and the 
like. The second tier administrative web pages 706 are 
illustratively linked to two third tier web pages 902 con- 
taining information from which an administrator may select. 
The third tier web pages 902 include an administrator tools 
web page 904 and an administrator reports web page 906. 
Any message sent by a service provider to the employer 
(such as a third party administrator) will be delivered 
through the forced delivery system as had by the participant; 
any documents viewed or unviewed by the plan adminis- 
trator is similarly longed at the service provider's level. 
[0083] The administrator tools web page 904 contains 
links to fourth tier web pages (not shown). These fourth tier 
web pages in the hierarchical structure include plan tools, 
which allow an administrator to add a new plan or modify 
existing plan information; communications tools, which 
allow an administrator to upload plan communications; and 



participant tools, which allow an administrator to add a 
participant or modify an existing participants status to an 
existing plan. This is done through a "wizard" type of 
inquiry (all pre-configured with the help of logic provided 
by Employee Benefits Consultants). 
[0084] The administrator reports web page 906 also pro- 
vides links to fourth tier web pages. The additional fourth 
tier web pages (not shown) provide an administrator with the 
capability of preparing and viewing, via the web pages, plan 
reports, communication reports, user defined reports and 
participant reports. 

[0085] The system of the present invention rids employee 
benefit sponsors of most of the manual delivery, recordation, 
and physical storage of paper that currently burdens them. 
Thus, the delivery and recordkeeping costs relating to paper 
transactions are dramatically reduced, as are the overall cost 
of maintaining those plans. Plan sponsors employing the 
system will yield immediate visible bottom line savings. 
Plan sponsors also benefit from higher HR personnel pro- 
ductivity, as those personnel are able to focus instead on the 
core competencies of their business, policy issues, and more 
"big picture" business tasks. Higher productivity comes 
from the ability of the plan sponsor to instantly query any 
employee, employer, or plan service provider activity by 
plan type, participant, date, communication, viewed/un- 
viewed status, and the like. The invention permits the mining 
of all data to produce instant and real-time reporting and 
monitoring capabilities. 

[0086] Unlike the current regime of paper-intensive plan 
administration, HR personnel utilizing the system are 
relieved from spending any time in determining which 
employee needs which notice and when. Moreover, the 
sponsor is able to electronically document that a notice was 
sent consistent with federal and/or state mandate, with 
confirmed receipt. For plan administrators with participants 
lacking access to a computer, the system is accessible from 
"kiosks" at centrally located workstations. A kiosk, in a 
sense, is an automated teller machine ("ATM") for employee 
benefit information, where, instead of viewing savings 
account and checking balances, the user sees for example, 
the balance in his retirement plan. Likewise, instead of 
moving money from a certificate of deposit ("CD") to a 
checking account, the user moves eligible floating holidays 
from his vacation bank to his sick leave bank. 
[0087] Finally, the system can identify which participant 
failed to access a computer or kiosk to receive and read a 
required notice, and then provide notice to the plan admin- 
istrator indicating who must receive plan documents through 
other than automated means. Similarly, the system can 
identify if a plan administrator failed to access the system to 
receive and read a required notice sent by a service provider. 
[0088] Although various embodiments that incorporate 
the teachings of the present invention have been shown and 
described in detail herein, those skilled in the art can readily 
devise many other varied embodiments that still incorporate 
these teachings. 



What is claimed is: 

1. A method for automatically identifying, distributing, 
recording, and re-creating communications electronically to 
selective participants of a plan, comprising: 
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providing a database containing plan and plan participant 
information; 

denning a plurality of plan rules associated with plan and 
plan participant information; 

defining a plurality of event triggers based on the plurality 
of plan rules; 

determining if an event trigger initiates delivery of at least 
one plan communication medium; 

determining a plan participant recipient listing; 

providing access to view the at least one plan communi- 
cation medium; and 

confirming the selective participants have viewed the at 
least one plan communication medium. 

2. The method of claim 1 wherein the defining a plurality 
of plan rules is performed by a plan sponsor. 

3. 'ITie method of claim 1, wherein the defining a plurality 
of event triggers is denned by a programmer selected from 
the group comprising a plan sponsor and a plan administra- 

4. The method of claim 1 wherein the plan communica- 
tions medium is selected from the group comprising a plan 
document, a plan form, a plan report, and a notification. 

5. ITie method of claim 4 wherein the at least one plan 
communications medium is generated from the database. 

6. The method of claim 1 wherein the determining the 
plan participant recipient listing comprises the step of ini- 
tiating a message transmission module in an instance where 
the event trigger has occurred. 

7. The method of claim 6 wherein the initiating step 
comprises the steps of: 

identifying the at least one plan communications medium 

that is to be delivered; and 
identifying at least one recipient of the at least one plan 

communications medium. 

8. The method of claim 7 further comprising the step of 
electronically delivering the at least one plan communica- 
tions medium automatically to the at least one recipient. 

9. The method of claim 8 further comprising the step of 
manually delivering the at least one plan communications 
medium to the at least one recipient. 

10. The method of claim 9 wherein the manual delivery 
step further comprises the steps of: 

setting a predetermined period of time for the participants 
to read the at least one plan communications medium 
delivered electronically; 

determining whether the at least one electronically deliv- 
ered communications has been read by each partici- 
pant; 

initiating an event trigger in an instance where the at least 
one electronically delivered communications has not 
been read; and 

notifying a plan administrator. 

11. The method of claim 1 wherein the confirmation step 
further comprises the steps of: 

enabling selected web site pages for viewing; 
providing an electronic signature affirmation; and 
receiving such electronic signature affirmation. 



12. The method of claim 1 wherein the confirmation step 
further comprises the step of prohibiting the participants 
from viewing a plan web site in an instance where any of the 
at least one plan communication medium, which are deemed 
relevant, are not confirmed as being read by the participants. 

13. The method of claim 12 wherein the prohibiting step 
further comprises the steps of: 

requesting the plan participant to login to a plan web site; 

presenting a communications viewer to the participant; 
and 

enabling the plan participant to select and retrieve the at 

14. The method of claim 12 further comprising the step of 
permitting the plan participant access to the plan web site 
upon confirming that all of the relevant at least one plan 
communications medium have been read by the plan par- 
ticipant. 

15. The method of claim 1 wherein the defining of the 
plurality of event triggers further comprises, storing in a 
trigger event database for each trigger event, an entry 
identification a trigger description, an associated plan com- 
munications medium, a trigger criteria, and trigger type. 

16. A computer-readable medium having instructions or 
programs which, when executed by a process cause the 
process to perform a method for automatically distributing 
communications electronically to participants of a plan, 
comprising: 

providing a database containing plan and plan participant 
information; 

defining a plurality of plan rules associated with the plan 

and plan participant information; 
defining a plurality of event triggers based on the plurality 

of plan rules; 

determining if an event trigger initiates delivery of at least 
one plan communication medium; 

determining a plan participant recipient listing; 

providing access to view the at least one plan communi- 
cation medium; and 

confirming the selective participants have viewed the at 
least one plan communication medium. 

17. The computer readable medium of claim 16, wherein 
the defining a plurality of event triggers is defined by a 
programmer .selected from the group comprising a plan 
sponsor and a plan administrator. 

18. The computer readable medium of claim 16 wherein 
the plan communications medium is selected from the group 
comprising a plan document, a plan form, a plan report, and 
a notification. 

19. The computer readable medium of claim 18 wherein 
the at least one plan communications medium is generated 
from the database. 

20. The computer readable medium of claim 16 wherein 
the determining the plan participant recipient listing com- 
prises the step of initiating a message transmission module 
in an instance where the event trigger has occurred. 

21. The computer readable medium of claim 20 wherein 
the initiating step comprises the steps of: 

identifying the at least one plan communications medium 
that is to be delivered; and 
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identifying at least one recipient of the at least one plan 
communications medium. 

22. The computer rcadahlc medium of claim 21 further 
comprising the step of electronically delivering the at least 
one plan communications medium automatically to the at 
least one recipient. 

23. 'fhe computer readable medium of claim 22 further 
comprising the step of manually delivering the at least one 
plan communications medium to the at least one recipient. 

24. The computer readable medium of claim 23 wherein 
the manual delivery step further comprises the steps of: 

setting a predetermined period of time for the participants 
to read the at least one plan communications medium 
delivered electronically; 

determining whether the at least one electronically deliv- 
ered communications has been read by each partici- 
pant; 

initiating an event trigger in an instance where the at least 
one electronically delivered communications has not 
been read; and 

notifying a plan adm i tr I 

25. The method of claim 16 wherein the confirmation step 
further comprises the steps of: 

enabling selected web site pages for viewing; 

providing an electronic signature affirmation; and 

receiving such electronic signature affirmation. 

26. The computer readable medium of claim 16 wherein 
the confirmation step further comprises the step of prohib- 
iting the participants from viewing a plan web site in an 
instance where any of the at least one plan communication 
medium, which are deemed relevant, are not confirmed as 
being read by the participants. 

27. The computer readable medium of claim 26 wherein 
the prohibiting step further comprises the steps of: 

requesting the plan participant to login to a plan web site; 

presenting a communications viewer to the participant; 
and 

enabling the plan participant to select and retrieve the at 
least one plan communications medium. 

28. The computer readable medium of claim 26 further 
comprising the step of permitting the plan participant access 
to the plan web site upon confirming that all of the relevant 
at least one plan communications medium have been read by 
the plan participant. 

29. The computer readable medium of claim 16 wherein 
the defining of the plurality of event triggers further com- 
prises, storing in a trigger event database for each trigger 
event, an entry identification, a trigger description, an asso- 
ciated plan communications medium, trigger criteria, and a 
trigger type. 

30. An apparatus, for automatically distributing, record- 
ing, monitoring, and re-creating communications electroni- 
cally to participants of a plan, comprising: 

a server providing a plan database, 

a plurality of event triggers associated with the plan 
database; 



a plurality of plan communications medium associated 
with the plan database and the plurality of event 
triggers; 

a transmission module coupled to the plan database; 

a plurality of plan participant computers and 

a communications network coupled to the server and 
plurality of plan participant computers, wherein at least 
one of the plurality of plan communications medium 
are provided electronically to at least one of the plu- 
rality of plan participant computers in an instance 
where at least one of the plurality of event triggers is 
initiated. 

31. 'llie apparatus of claim 30 wherein the communica- 
tions medium (208) is selected from the group comprising 
plan documents, plan forms, plan reports, and plan notifi- 

32. The apparatus of claim 30 wherein the at least one 
communication medium is generated from the database. 

33. The apparatus of claim 30 wherein the communica- 
tions network is selected from the group comprising the 
Internet, Intranet, local area network, and wide area net- 

34. The apparatus of claim 30 wherein the plurality of 
event triggers further comprises, for each trigger event, an 
entry identification, a trigger description, an associated plan 
communications medium, a trigger type, and a trigger cri- 

35. The apparatus of claim 34 further comprising a plan 
web site. 

36. The apparatus of claim 35 wherein the plan web site 
comprises a plurality of web pages having a hierarchical 

37. The apparatus of claim 36 wherein the web site 
provides connectivity to an administrator hierarchy of web 
pages, a participant hierarchy of web pages, and a commu- 
nications viewer. 

38. The apparatus of claim 37 wherein the communica- 
tions viewer provides plan participant access to read the 
delivered at least one plan communications medium. 

39. The apparatus of claim 38 wherein the communica- 
tions viewer further comprises a personal file cabinet. 

40. The apparatus of claim 39 wherein the personal file 
cabinet permanently stores archived communication 
medium unique to each of the participants and, further, 
unique to an employer. 

41. A method for automatically distributing plan commu- 
nications electronically to participants of a plan comprising: 

sending an electronic mail communication inviting access 
to a web site; 

waiting for access to the web site for a predefined period 

sending an alternate communication after the predefined 
period of time has surpassed. 

42. The method of claim 41 wherein the waiting step 
further comprises the step of receiving a confirmation from 
the participants of the plan having viewed the communica- 

43. The method of claim 42 wherein the receiving the 
confirmation step further comprises receiving an electronic 
signature. 
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44. The method of claim 41 further comprising the step of 
permitting the participants having confirmed viewing the 
plan communications to access additional plan web pages. 

45. The method of claim 41 wherein prior to said sending 
an alternate communication, the method further comprises: 



sending a second electronic mail communication; and 
waiting for access to the web site for a second predefined 
period of time. 
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(57) ABSTRACT 
Disclosed is a computer-implemented method for automatic 
remote coding of a debtor credit card account database with 
bankruptcy filing information comprising, at a local data 
processing location, the steps of collecting bankruptcy filing 
reports from courts located within the various jurisdictions 
for which the method provides coverage, extracting unique 
debtor identifying data from the bankruptcy filing reports, 
and generating a database query designed to identify data- 
base records which match the unique debtor identifying 
data; the step of establishing an electronic connection 
between the local data processing location and a remote 
credit database storage location, the electronic connection 
being suitable for two-way transmission of data between the 
local data processing location and the remote credit database 
storage location; the step of executing, from the local data 
processing location, the database query against a debtor 
credit database housed at the remote credit database storage 
location and identifying debtor records matching the data- 
base query; and the step of coding the matching records at 
the debtor credit database with bankruptcy filing informa- 
tion. 
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United States Bankruptcy Court District of 
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Chapter 7 Bankruptcy Case, Meeting of Credjtors, & Deadlines 


[A chapter 7 bankruptcy case concerning the debtorO) I 
or [A bankruptcy case concerning the debtor(s) listed t 
fdatel and was converted to a 
You may be a creditor of the debtor. This notice list! impoi 

NOTE: The stall of the bankruptcy clerk's office caroMtgiw 


sled below was filed on fditeV| 

elow was originally filed under chapter on 

case under chapter 7 on .1 
tant deadlines. You may want to consult an attorney to proteel 
Bted at the bankruptcy clerk's office at the address listed below, 
legal advice. 


See Reverse Side For Important Explanations. 


Debtors) (name(>) and address): 


Case Number: 




Social Security/Taxpayer IDNos.: 


Attortwy for Debtorfe) (name and addrecs): 


Bankruptcy Trustee (name and address): 


Telephone number: 


Telephone number: 


Meeting of Creditors: 


Date: / / Time: ( )km. Location: i 

( )'M. 


' Deadlines: 

Papers m ust be received by trie bankruptcy clerk's ofBoeby SwfoUowiiig deadiines: - 


Deadline to FiU a Complaint Objecting u Discharge of ibc Debtor or to DetcrmiseDischargeabllity or Certain Debts: 
Dcadlincio Object to Eicmptitm: 
Thirty (30) days after the conclusion of the meeting of creditors. 


Creditors' May Not Take Certain . Actions . . . 


If you attempt to oolleet a debt or take other action in violation of the Bankruptcy Code, you may be penalized. 


Please Do Not File A Proof of Claim Unless You Receive a Notice To Do So. 


Address or Ibe Bankruptcy aerie's Office,- 


Forthe Cc-urt:. . 




Clerk of the Bankruptcy Court: 


Telephone number: 




Hours Open: 


Date: 
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COMPUTER-BASED METHOD FOR AUTOMATIC 
REMOTE CODING OF DEBTOR CREDIT 
DATABASES WITH BANKRUPTCY FILING 
INFORMATION 

FIELD OF INVENTION 

[0001] The present invention relates generally to methods 
for remotely searching for, locating and updating selected 
records from a remotely located database and the present 
invention specifically relates to a method of remotely coding 
records in debtor credit card account databases with infor- 
mation regarding bankruptcy filings. 

BACKGROUND OF THE INVENTION 

[0002] The consumer credit card industry has enjoyed 
explosive growth in the past decade. The tremendous growth 
in the industry has required credit card providers, and 
third-part)' administrators of those accounts, to computerize 
their account processing and handling activities as much as 
possible. One aspect of processing and handling of credit 
card accounts which is particularly automated is billing, and, 
particularly as it relates to the present invention, collection 
activities directed at holders of delinquent accounts. 
[0003] In order to maintain proper controls over the status 
of consumer accounts, credit card issuers (hereinafter "Issu- 
ers") have developed specialized computer applications 
which analyze critical information concerning credit card 
accounts and initiate particular collection-related activities 
when certain thresholds have been met. For instance, an 
initial "past due" letter may be sent to the holder of a credit 
card (hereinafter "Holder") once payment has not been 
received for a certain number of days after the payment due 
date. More stringent measures, such as the referral of an 
account to the Issuer's collections department, a collection 
agency, or to an outside attorney, may follow if the number 
of days the account is past due exceeds a second or subse- 
quent threshold. 

[0004] The success rate of an Issuer's automated collec- 
tion efforts depends on the accuracy and completeness of the 
financial data it maintains for each of the accounts it 
services. For this reason, Issuers place tremendous reliance 
on large and sophisticated account databases which are 
updated millions of times each day to ensure their accuracy 
and completeness. 

[0005] The account databases maintained by Issuers con- 
tain information about each credit card account and Holder 
which is critical for the correct processing of payments and 
for the commencement, tracking, and termination of collec- 
tions activities. For example, the credit card account data- 
bases contain basic contact information about each account, 
the balance due for each account, and the date or dates when 
payments are supposed to be made by the credit card holder. 
Another piece of information which is usually maintained by 
an Issuer in its database of accounts is the bankruptcy status 
of the account's Holder. The electronic manipulation of this 
bankruptcy status information is the central focus of the 
present invention. 

[0006] Issuers place great emphasis on the maintenance of 
accurate information about the bankruptcy status of Holders 
because federal laws in the United States require them to not 
commence collections activities against any Holder who 



files for bankruptcy relief. 'JTie same laws require any 
activity related to the collection of a debt to be immediately 
suspended or "stayed" by the Issuer once it receives notice 
that the Holder has filed for bankruptcy. The penalties to 
which the Issuer is subject for failing to cease collection 
activities once it receives formal notice of a bankruptcy 
filing, or for commencing collections-related activity against 
a bankruptcy filer, can be severe. 

[0007] In addition, in order to preserve certain rights to 
collect, at least partially, monies due to it by a bankrupt 
Holder, an Issuer must, shortly after learning about the 
bankruptcy filing, or upon notice received, assert the debt to 
the appropriate bankruptcy court by filing a "proof of 
claim". Failure to file a timely proof of claim may cause the 
Issuer to forfeit any claim it may have to bankruptcy 
proceeds despite the existence of a valid debt and funds 
available to satisfy same. Other remedies which are also 
time-sensitive may be available to the Issuer as well. 

[0008] The problem faced by Issuers, particularly the 
larger entities, is that they have accounts which number in 
the hundreds of millions. As a consequence, they are named 
as creditors in hundreds of thousands of bankruptcy filings 
every day. Issuers are typically notified of the bankruptcy 
filing by one of their Holders, through a paper form issued 
by the court where the Holder files for bankruptcy. An 
electronic notice may also be received under certain circum- 
stances. The paper forms allow the Issuer, upon receipt, to: 
(a) extract the relevant information from the form; (b) locale 
accounts held by the Holder named in the form from among 
the millions of accounts serviced by the Issuer; (c) verify 
that the located Holder account or accounts are the correct 
ones; and (d) annotate the database with the bankruptcy 
information. This, in turn, ensures that activity on annotated 
accounts may be commenced or halted as necessary to be 
compliant with federal bankruptcy and banking laws. 
Because the paper forms are not always uniform from court 
to court, Issuer currently must perform these functions 
manually, which task carries with it a tremendous cost in 
manpower and resources and with reduced accuracy. 

[0009] A review of prior efforts reveals that a computer- 
based method for automatic remote coding of debtor credit 
databases with bankruptcy fifing information has never been 
realized. Previous attempts at automated methods relating to 
the coding of financial databases are described in U.S. Pat. 
No. 4,914,587 to Clouse, (the '587 patent); U.S. Pat. No. 
5,274,547 to Zoffel, (the '547 patent); U.S. Pat. No. 6,098, 
052 to Kosiba et al., (the '052 patent); U.S. Pat. No. 
5,323,315 to Highbloom, (the '315 patent); U.S. Pat. No. 
5,615,408 to Johnson et al. (the '408 patent); U.S. Pat. No. 
6,119,103 to Basch et al., (the '103 patent); and U.S. Pat. No. 
5,426,281 to Abecassis, (the '281 patent), each of which is 
incorporated here by reference. 

[0010] The '587 patent describes a financial data process- 
ing system utilizing two levels of distributed processors 
interconnected to one another and a central processor inter- 
connected to the first level of distributed processors. The 
financial data being processed includes loan information 
representing the balance of each loan outstanding, the inter- 
est rate payable on each loan, the principal and interest due 
and payable for each periodic loan payment, the identity of 
each debtor, the delinquency, if any, on each loan, the 
collection histories of respective loans and financial infor- 
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mation relating to leases and leased property. In one embodi- 
ment, the system provides for the high speed entry of data 
utilizing optical character readers which are utilized to scan 
customer statements containing pre-printed financial data in 
a format and type recognizable by the optical character 

[0011] The '547 patent describes a system and method for 
automatically generating credit reports. The system includes 
a central data processing facility which is connectable to 
national credit repositories through dedicated data links. The 
central data processor requests credit information on an 
applicant from one or more of the repositories, generates a 
credit report, and transmits the report to the requesting user 
(i.e., customer). Requests and reports are transmitted via a 
communications system or network. If data is inputted from 
more than one repository, the central data processing facility 
eliminates duplicated data, selects the best data if there arc 
conflicts, and merges the remaining data into a single report. 
[0012] The '052 patent describes a computerized collec- 
tion strategy model for use in collecting payments from 
delinquent accounts. 'Jhe computerized collection strategy 
model estimates for each possible collection strategy, how 
much will be paid on each account in response to that 
collection strategy, estimates the amount of resources to be 
expended in the execution of that collection strategy, and 
recommends a particular collection strategy for each account 
that optimizes the use of the available collection resources. 
[0013] The '315 patent describes a system for monitoring 
the status of individual items of personal property which 
serve as collateral for securing financing. The system 
receives financing information from a first financing source 
and a second financing source. A unique identification code 
is associated with each individual item of personal property 
which serves as collateral for securing financing from the 
first and second financing sources. The financing informa- 
tion from the first financing source is compared with the 
financing information from the second financing source 
based at least in part upon the identification codes of the 
items of personal property to identify particular items of 
personal property that simultaneously serve as collateral to 
secure financing from both the first and second financing 
sources. The affected first and second financing sources are 
notified about the identified item of personal property. 
[0014] The '408 patent describes an apparatus for credit 
based management of a telecommunication system. One 
embodiment of the apparatus includes an interface for 
communicating credit information on a particular subscriber 
and for receiving call records for the particular subscriber 
that are derived from a switch which establishes connections 
between telecommunication devices. A credit limit device 
then utilizes the credit information to establish a credit limit 
for the subscriber. The apparatus also includes a device for 
comparing the particular subscriber's call usage to a credit 
limit established for the subscriber based on information 
obtained from the credit bureau. An output device is used to 
provide an indication that the subscriber has exceeded their 
credit limit. Another embodiment of the apparatus, includes 
a device for, upon expiration of a predetermined time period, 
contacting the credit bureau to obtain a new credit score for 
a subscriber and use this score to update the subscriber's 
credit limit. 

[0015] The '103 patent describes a computer-implemented 
method for predicting financial risk, which includes receiv- 



ing first transaction data pertaining to transactions per- 
formed on a first financial account. The first financial 
account represents a financial account issued to a given 
account holder by a first account issuer. The method further 
includes receiving second transaction data pertaining to 
transaction performed on a second financial account differ- 
ent from the first financial account. The second financial 
account represents a financial account issued to the given 
account holder by a second account issuer different from the 
first account issuer. There is further included scoring the first 
transaction data and the second transaction data based on a 
preexisting model to form a score for the account holder. 
Additionally, there is included transmitting, if the score is 
below a predefined financial risk threshold, the score to one 
of the first account issuer and the second account issuer. 
[0016] The '281 patent describes a transaction protection 
system that permits non-related third parties to offer an 
impartial, readily accessible standardized service that will 
protect and encompass any moneys that arc tendered by an 
individual or business entity to a transaction in relation to a 
second business or entity. Delivery of payment will occur 
upon a future condition being met automatically whereby 
the system both performs an escrowing function, a payment 
function and a notifying function automatically. The trans- 
action processing system acts as a temporary depository 
control in the flow of the moneys from parties in a transac- 
tion ensuring that sufficient balances are available for the 
transaction and assuring that payment is made only upon 
satisfaction of the conditions set by the parties to the 
transaction. The system is implemented by means of either 
an integrated credit/debit system, deposit slips and forms or 
through conventional checks combined with either credit 
card or deposit slips. The system may be implemented using 
site dependent or site independent (portable) point of sales 
terminals, computers or touch tone telephones. The system 
further implements electronic accessing means for allowing 
cither of the parties to the transaction to affect the processing 
of the transaction. 

[0017] None of the inventions described in the prior art 
include a computer-based method for coding of databases 
which automatically extracts bankruptcy filing information 
received in a variety of formats and seamlessly interacts 
with a remote credit card account database to update indi- 
vidual account records therein with said bankruptcy infor- 
mation to help ensure adequate compliance with applicable 
debt collection laws. 

[0018] Accordingly, there is a need in the prior art for a 
computer-based method for coding of debtor credit card 
account databases with bankruptcy filing information which 
significantly automates the process of extracting data from 
paper-based or electronic notices regarding the filing of new 
bankruptcies or changes in the status of existing bankrupt- 

[0019] There is a further need in the prior art for a 
computer-based method for coding of debtor credit data- 
bases with bankruptcy filing information which facilitates 
and automates the coding of remote credit databases through 
the use of a widespread computer network. 
[0020] There is a further need in the prior art for a 
computer-based method for coding of debtor credit data- 
bases with bankruptcy filing information which can interact 
remotely, with minimal adaptation, with different types of 
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credit databases regardless of the database vendor, the 
computer language used to program and access the database, 
the database configuration, or the access rules governing the 
database. 

[0021] There is yet a further need in the prior art for a 
computer-based method for coding of debtor credit data- 
bases with bankruptcy filing information which can auto- 
matically generate comprehensive reports detailing all 
changes made to said databases. 

SUMMARY OF THE INVENTION 
[0022] The present invention overcomes significant defi- 
ciencies in the prior art by providing a computer-imple- 
mented method for automatic remote coding of a debtor 
credit card account database with bankruptcy filing infor- 
mation comprising, at a local data processing location, the 
steps of collecting bankruptcy filing reports from courts 
located within the various jurisdictions for which the method 
provides coverage, extracting unique debtor identifying data 
from the bankruptcy filing reports, and generating a database 
query designed to identify database records which match the 
unique debtor identifying data; the step of establishing an 
electronic connection between the local data processing 
location and a remote credit database storage location, the 
electronic connection being suitable for two-way transmis- 
sion of data between the local data processing location and 
the remote credit database storage location; the step of 
executing, from the local data processing location, the 
database query against a debtor credit database housed at the 
remote credit database storage location and identifying 
debtor records matching the database query; and the step of 
coding the matching records at the debtor credit database 
with bankruptcy filing information. 
[0023] Accordingly, it is an object of the present invention 
to provide a computer-based method for coding of debtor 
credit databases with bankruptcy filing information which 
significantly automates the process of extracting data from 
paper-based or electronic notices regarding the filing of new 
bankruptcies or changes in the status of existing bankrupt- 

[0024] It is an additional object of the present invention to 
provide a computer-based method for coding of debtor 
credit databases with bankruptcy filing information which 
facilitates and automates the coding of remote credit data- 
bases through the use of a widespread computer network. 
[0025] It is an additional object of the present invention to 
provide a computer-based method for coding of debtor 
credit databases with bankruptcy filing information which 
can interact remotely, with minimal adaptation, with differ- 
ent types of credit databases regardless of the database 
vendor, the computer language used to program and access 
the database, the database configuration, or the access rules 
governing the database. 

[0026] It is an additional object of the present invention to 
provide a computer-based method for coding of debtor 
credit databases with bankruptcy filing information which 
can automatically generate comprehensive reports detailing 
all changes made to said databases. 

[0027] These and other objects, features, and advantages 
of the present invention may be more clearly understood and 
appreciated from a review of ensuing detailed description of 



the preferred and alternate embodiments and by reference to 
the accompanying drawings and claims. 

BRIEF DESCRIPTION Oi' Tl IE DRAWINGS 
[0028] FIG. 1 is a schematic block diagram which shows 
the interrelationship between different hardware and soft- 
ware components of the system. 

[0029] FIG. 2 is a schematic representation of the data- 
base structure used in the preferred embodiment of the 
present invention. 

[0030] FIGS. 3A-3C arc a flowchart illustrating the basic 
steps in the operation of the present invention. 
[0031] FIG. 4 is an illustration of a sample blank Notice 
of Chapter 7 Bankruptcy Case of the type processed by the 
preferred embodiment of present invention. 
[0032] FIG. 5 is an illustration of the user interface for the 
custom data-entry application used in the preferred embodi- 
ment of the present invention. 

[0033] FIG. 6 is an illustration of a sample activity report 
generated using the preferred embodiment of the present 



DETAILED DESCRIP TION OF 'THE 
PREFERRED EMBODIMENT 
[0034] Referring initially to FIG. 1 of the drawings, in 
which like numerals indicate like elements throughout the 
several figures, the environment in a preferred embodiment 
of the present invention includes at least one Court T-ocation 
10, at least one Issuer Location 20 and at least one Process- 
ing Location 30. It is envisioned al present that each of the 
three aforementioned locations will be housed in a separate 
physical building, however, a separate geographic presence 
for each location is not necessary for the present invention 
to function. The Court Locations 10 can transmit paper- 
based communications to the Issuer Locations 20 and the 
Processing Locations 30 by means of traditional methods 
such as mail, messenger service, facsimile, telegraph, and 
the like 12. The Court Locations 10 can transmit electronic- 
based communications to the Issuer Locations 20 and the 
Processing Locations 30 by means of an electronic link 14 
which is in turn connected to an electronic communications 
network, such as the Internet 40. 

[0035] Each Issuer Location 20 is equipped with a com- 
munications processing facility 22 which is responsible for 
receiving communications from the Court Locations 10 and 
transmitting communications to the Processing Locations 
30. The Issuer Location communications processing facility 
22 can receive communications from the Court Locations 10 
via traditional methods such as mail, messenger service, 
facsimile, telegraph, and the like 12 or via an electronic link 
14 connection lo an electronic communications network, 
such as the Internet 40. Similarly, 'The Issuer Location 
communications processing facility 22 can transmit com- 
munications to the Processing Location communications 
processing facility 32 via traditional methods such as mail, 
messenger service, facsimile, telegraph, and the like 12 or 
via an electronic link 14 connection to an electronic com- 
munications network, such as the Internet 40. 
[0036] Also housed at the Issuer Location 20 is at least one 
credit card account database 24 which contains account 
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information, including bankruptcy status information, about 
credit cards issued by the Issuer. The credit card account 
database 24 is accessible by electronic means to computers 
external and internal to the Issuer. An example of a computer 
having access to the credit card account database 24 is an 
account processing facility 26 which can be, but need not be, 
physically housed at the Issuer Location. The account pro- 
cessing facility 26 could, for example, obtain information 
from the credit card account database for billing purposes or 
in order to initiate or terminate collection-related activities. 

[0037] Each Processing Location 30 is equipped with a 
communications processing facility 32 which is responsible 
for receiving communications from the Court locations 10 
and from the Issuer Locations 20. The Processor Location 
communications processing facility 32 can receive commu- 
nications from the Court Locations 10 and the Issuer Loca- 
tions 20 via traditional methods such as mail, messenger 
service, facsimile, telegraph, and the like 12 or via an 
electronic link 14 connection to an electronic communica- 
tions network, such as the Internet 40. Similarly, the Pro- 
cessing Location communications processing facility 32 can 
transmit communications to the Issuer Locations 20 via 
traditional methods such as mail, messenger service, fac- 
simile, telegraph, and the like 12 or via an electronic link 14 
connection to an electronic communications network, such 
as the Internet 40. 

[0038] Also housed at the Processing Location 30 is at 
least one notice processing facility 34 where bankruptcy- 
related notices received by the Processing Location are 
processed in order to ultimately generate updates to the 
credit card account database 24. The notice processing 
facility 34 is linked electronically to the Processing Loca- 
tion's communications processing facility 32 through a 
traditional internal network infrastructure such as a Local 
Area Network ("LAN") 36. Alternatively, if the notice 
processing facility 34 is at a location different than the 
communications processing facility 32, communication 
between the two locations may be established through a 
Wide Area Network ("WAN") or through the Internet 40. 

[0039] Finally, the notice processing facility 34 is also 
linked electronically 16 to the credit card account database 
24 by means of a WAN, LAN, through the Internet or by any 
other standard network connection. 

[0040] At the heart of the preferred embodiment of the 
present invention lies an integrated set of database applica- 
tions residing inside computers located at the notice pro- 
cessing facility 34. These applications receive new bank- 
ruptcy-related notices, processes them, remotely link with 
and update the credit card account databases 24 and generate 
reports detailing these activities. The general database struc- 
ture for these applications is described in FIG. 2. 

[0041] In the preferred embodiment, the database structure 
is composed of several database constructs which are 
referred to hereinafter as Logical Units ("LUs"). In abstract 
terms, an LU is a logical representation of a database or a 
subset of a database. In the present instance, an LU is a 
collection of tables and similar database constructs which 
are related by means of rules defining relationships between 
the constructs. 

[0042] Referring now to FIG. 2, the central database LU 
is called a Case LU 200. The Case LU 200 contains 



information about each individual bankruptcy-related notice 
processed by the system. The information contained in the 
Case LU 200 includes case-specific data such as the court 
case number, the filing date, the Issuer or issuers affected by 
the Notice, the type of bankruptcy and the type or types of 
notices received. The Case LU 200 is linked, or "related", to 
several other LUs which contain additional information 
applicable to the cases stored in the Case LU 200. Additional 
LUs which are related to the Case LU 200 include: the Entity 
LU 210, the Court LU 220, the Judge LU 225, the Attorney 
LU 230, the Trustee LU 240, the Issuer LU 260, and the 
Processed Account LU 270. 

[0043] The Entity LU 210 contains data about all indi- 
viduals, corporations or other legal entities who are Holders 
of an Issuer's credit card and are identified as debtors in 
bankruptcy filings where the Issuer is identified as a creditor. 
The Entity LU 210 contains information such as names, 
addresses, social security numbers, federal lax identification 
numbers, telephone numbers, and the like, for each entity. 
[0044] The Court LU 220 contains data about the different 
courts from which an Issuer has received information on 
bankruptcy filings naming the Issuer as a creditor. The Court 
LU 220 contains information such as the address, names of 
clerks, telephone numbers, and the like, for each court. 
[0045] The Judges LU 225 contains data about the differ- 
ent judges presiding over bankruptcy cases for which an 
Issuer has received information on bankruptcy filings nam- 
ing the Issuer as a creditor. The Judges LU 220 contains 
information such as the address, names, telephone numbers, 
and the like, for each judge. 

[0046] The Attorney LU 230 contains data about the 
different attorneys named in bankruptcy filings where the 
Issuer is identified as a creditor. The Attorney LU 230 
contains information such as lawyers names, law firm 
names, addresses, telephone numbers, and the like, for each 
attorney. 

[0047] Each Issuer serviced by the method of the present 
invention, has a corresponding Issuer LU 260 and Processed 
Account LU 270. Each Issuer LU and Processed Account 
LU 270 contains data about its corresponding Issuer. 

[0048] Each Issuer LU 260 contains information such as 
addresses, telephone numbers, kinds of credit cards, data- 
base locations and access information, and the like, for each 
Issuer. The Issuer LU 260 also contains information about 
the Issuer's computer system, its structure, "front-end" 
applications used to access the credit card account database 
24 and handling instructions for particular types of bank- 
ruptcy-related notices. 

[0049] Each Processed Account LU 270 contains data 
about the different accounts for its corresponding Issuer 
which have been processed using the method of the present 
invention. The Processed Account LU 270 contains infor- 
mation such as account numbers, balances, bankruptcy 
status, types of notices processed, and the like, for each 
Issuer account processed. 

[0050] The Case LU 200, the Entity LU 210, the Court LU 
220, the Judge LU 225, the Attorney LU 230, the Trustee LU 
240, the Issuer LU 260, and the Processed Account LU 270 
are all related to form a cohesive repository of data con- 
taining all of the relevant information extracted from bank- 
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ruptcy notices received at the Processing Location 30. Every 
record in the Entity LU 210, the Court LU 220, the Attorney 
LU 230, the Trustee LU 240, the Issuer LU 260, and the 
Processed Account LU 270 is indexed to at least one record 
in the Case LU 200. Using this relationship between the 
different LUs, it is possible to quickly and efficiently gen- 
erate a data structure element which contains all of the 
information necessary to update the credit card account 
database 24 with the information contained in a single 
bankruptcy-related notice. These data structure elements, 
akin to records in a "virtual" database table, are hereinafter 
referred to as Software Objects ("SOs"). SOs do not only 
contain data but also contain routines that manipulate the 
data within the SO. Routines contained within an SO can, for 
example, be used to compare two SOs and determine 
whether their data matches. 

[0051] For example, a Bankruptcy SO is a collection of all 
of the known data about a particular bankruptcy case and 
contains information such as: the court case number, the 
case's filing date, the bankruptcy filer's identifying data, the 
court identifying data, the attorney identifying data, the 
judge identifying data, and the trustee identifying data. This 
information is obtained from all of the aforementioned LUs 
and assembled into a virtual record. An SO is said to be a 
"virtual" record because it is not permanently stored in any 
particular place but rather, it is formed "on-the-fly" as 
needed to perform a particular operation. 
[0052] In addition to a Bankruptcy SO, in the preferred 
embodiment of the present invention a number of other 
types of SOs can be created. Possible types of SOs include 
Entity SOs (including identifying information about an 
entity that is the subject of a bankruptcy-related notice, i.e. 
an individual or corporate debtor who lists an Issuer as a 
creditor); Court SOs, Attorney SOs and Attorney SOs. 
[0053] By using the above-described structure of related 
database LUs, the method of the present invention uses a 
more streamlined and efficient database than would be 
otherwise possible. For example, if a particular trustee is 
assigned to more than one bankruptcy filing (a likely sce- 
nario) and a "flat" database structure were used (i.e„ one not 
depending on a series of related LUs), the information for 
the trustee would be duplicated for every record of a filing 
to which he is assigned. By using related LUs, the trustee's 
information can be entered only once and then be associated 
with multiple case records. 

[0054] In addition to the LUs discussed above, which 
contain data about specific bankruptcy filing, the database 
structure of the present invention contains an additional type 
of LU, the Rules LU 250, which includes information about 
Comparison Rules (a term which is defined later in this 
specification) and thresholds necessary to match information 
contained in bankruptcy-related notices to particular 
accounts within accounts found in that Issuer's credit card 
account database 24. The Rules LU 250 also includes rules 
regarding the level of accuracy which is necessary to estab- 
lish that a record in the credit card account database matches 
information contained in a bankruptcy-related filing 
[0055] In the preferred embodiment of the present inven- 
tion, each Issuer will be assigned a record in the Rules LU 
250 that defines the Matching Rules (a term which is defined 
later in this specification) and Comparison Rules and thresh- 
olds applicable to that Issuer. 



[0056] The use of a Rules LU 250, as opposed to "hard 
coding" the database manipulation rules into a custom 
application, permits more flexibility in increasing the num- 
ber of Issuers whose credit card account databases can be 
annotated by the instant method. To wit, in order to be able 
to service a new Issuer's credit card account database, 
essentially, the only specialized code which needs to be 
written is a record in the Rules LU defining Matching and 
Comparison Rules and thresholds for that Issuer, and the 
creation of an Issuer LU 260 with information applicable to 
that Issuer. 

[0057] FIGS. 3A-3C generally depict the steps utilized in 
the present invention to update and annotate an Issuer's 
credit card account database 24 from the lime a bankruptcy 
related notice is filed. 

[0058] Beginning with FIG. 3A, the process starts with 
the filing of a bankruptcy petition in bankruptcy court by a 
debtor who is also a Holder 300. 1 Tie court upon commence- 
ment of a bankruptcy case issues a Notice of Commence- 
ment of Bankruptcy under either Chapter 7, Chapter 11, or 
Chapter 13 of the U.S. Bankruptcy Code (Title 11, United 
States Code). A sample blank Notice of Chapter 7 Bank- 
ruptcy Case is illustrated in FIG. 4. The bankruptcy court 
then transmits a copy of the notice 302 to every entity named 
as a creditor in the bankruptcy filing. Filings and notices 
subsequent to the initial petition are also transmitted to 
creditors named in the petition, or subsequently. In this case, 
if the Issuer is named as a creditor, the notice will be sent to 
the Issuer I-ocation 20. Once the Issuer receives the notice 
304, the notice is then immediately forwarded 306 to the 
Processing Location 30 by the Issuer Location's mail pro- 
cessing facility 22. It is also possible that the Issuer can 
register a standing request with the court in question that all 
notices which name the Issuer as a creditor be forwarded 
directly to the Processing Location 30. 
[0059] The bankruptcy notice is then received 308 by the 
Processing Location's mail processing facility 32 where it is 
readied for input into the system. The mail processing 
facility 32 can receive bankruptcy notices, either from the 
court or from the Issuer, in traditional paper format or as an 
electronic data file. 

[0060] If the notice is received as an electronic data file, it 
is formatted in a standardized way known to both the court 
and the notice processor. One such standard format, and the 
format used in the preferred embodiment of the present 
invention, is the Electronic Data Interchange ("EDI") for- 
mat. In the preferred embodiment, a notice received in 
electronic format is first parsed into fields in a temporary 
database table 316 and then individual fields from the 
temporary table are mapped to their corresponding fields in 
the applicable LU (i.e., Case, Attorney, Court, and Trustee 
LUs) 318. The information in the temporary table is then 
checked for matches against records in the Bankruptcy, 
Case, Attorney, Court, Trustee, Issuer and Processed 
Account LUs 320. If a record matches, this means that the 
information is already in the Processing Location's database 
LUs and is discarded 321. If a record does not match, it 
means it is new information and the data is written to the 
appropriate LU 322. 

[0061] If the notice is received as a paper document, the 
data it contains must be extracted and fixed in digital format 
for inputting into the appropriate database LUs. This can be 
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accomplished by having a data-entry operator manually key 
in the data into a database front-end application or by using 
an automated scanning application which can be pro- 
grammed to learn the location of relevant data on the notice 
and use optical character recognition ("OCR") techniques to 
automate the data entry. 

[0062] Because the forms used by bankruptcy courts for 
transmitting notices arc not always uniform, and because the 
quality of the text in the notices is not always suitable for 
OCR operations, the preferred embodiment of the present 
invention utilizes a semi-automated method of data entry for 
paper forms. The scmi-automatcd method is initiated by 
processing the paper notice with an optical computer scan- 
ner to create a computer-based graphical image of the notice 
310. The graphical image is then transmitted through a 
computer network to a custom data-entry computer appli- 
cation 311. 

[0063] The custom data-entry application, illustrated in 
FIG. 5, presents a human operator with a split screen on a 
computer monitor 500. One side of the screen displays the 
image of the paper notice to be processed 510 and the other 
side of the screen displays fields for the entry of specific 
information to be extracted from the image by the human 
operator 520. As the operator keys in information 312 into 
the data-entry side of the screen 520, the information is 
temporarily saved by the data entry application. As with 
electronically formatted notices, the temporarily saved data 
is compared for matches against records in the Bankruptcy, 
Case, Attorney, Court, Trustee, Issuer and Processed 
Account LUs and only unmatched records are permanently 
written to the appropriate LUs 322. 

[0064] Continuing with FIG. 3B, every time a new 
records is written into the Case LU 200, signifying that a 
new bankruptcy-related notice has been received and 
entered, a monitoring mechanism of the database application 
of the present invention generates a "trigger" event 324. The 
"trigger", in turn, generates a process request 326 which 
references the new record written to the Case LU 200. A 
process request can be a record which is written to the 
applicable Issuer LU 260. The process request can be 
immediately made available for handling or can be queued 
if the system is occupied with a previously issued process 
request 328. If a process request is queued, the queue may 
consist of a queued series of similar records inside the Issuer 
LU 260. 

[0065] The most recently issued process request, or the 
next process request in the process request queue, is routed 
to a "Bankruptcy Coding Software Object" ("BCSO") appli- 
cation which in turn executes the process request 330. The 
BCSO initially looks up the Jintity information for the Case 
record referenced by the process request. That is, the BCSO 
looks up the bankruptcy notice record in the Case LU 200 
and then determines, from the bankruptcy record, the cor- 
responding record in the Entity LU 210. BCSO then con- 
structs an Entity SO 331 from data fetched from the Entity 
LU 210. This Entity SO will be compared against entities in 
the subject Issuer's credit card account database 24 for 
possible matches and if one is found the credit card account 
database 24 will be updated with information from the 
bankruptcy notice being processed. 

[0066] After generating the Entity SO, the BCSO estab- 
lishes a communications link with the credit card account 



database 24 and begins searching for matches 332. BCSO 
conducts its search using the database rules contained in the 
record of the Rules LU 250 applicable to the credit card 
account database 24. As a preliminary step 333, the BCSO 
attempts to eliminate from contention as many records as 
possible from the credit card account database 24 since it 
generally contains a massive amount of records which 
would otherwise take a long time to completely check out 
individually. This step is usually carried out by building a 
result set of records obtained by querying the credit card 
account database 24 several times. Each query retrieving a 
subset of records singled out by using a number of criterion 
including but not limited to Social Security Number, Federal 
Employment ID Number, Last Name+First Name, and the 
like. 

[0067] Continuing with FIG. 3C, at step 334, the BCSO 
generates a Match Candidate SO from the first record 
returned by the preliminary query for comparison with the 
Entity SO generated from the Entity LU 210 in step 331. The 
Match Candidate SO's structure is, in essence, identical to 
the structure of the Entity SO, but is populated with data 
extracted from the credit card account database 24 instead of 
data from the various LUs. 

[0068] The Match Candidate SO and the Entity SO are 
compared 335 and if they do not match, the scripting object 
then generates 334 a new Match Candidate SO from the next 
record returned by the preliminary search and again com- 
pares the Match Candidate SO to the Entity SO 335. There 
may be multiple accounts returned by the preliminary search 
that contain Match Candidate SOs that truly match the 
Entity SO. Thus, all Holder information from all account 
records in the preliminary result set are compared against the 
Entity SO. 

[0069] Whenever a Match Candidate SO and the Entity 
SO are matched, the BCSO annotates the database record in 
the credit card account database 24 which corresponds to the 
Match Candidate SO 338. The annotation consists of revis- 
ing, if appropriate, the field in the credit card account 
database 24 which denotes the bankruptcy status of the 
Holder of the account and of writing any additional infor- 
mation about the bankruptcy notice which is specified in the 
Rules LU 250 entry for the database in question. Anytime a 
record in the credit card account database 24 is annotated, 
the BCSO also generates an entry in the associated Issuer's 
Processed Account LU 270. 

[0070] The Processed Account LU 270 is used, as a final 
step, to generate an activity report of all records annotated 
using the method of the present invention 340. A sample 
activity report is illustrated in FIG. 6. 

[0071] Finally, if the BCSO fails to generate a single 
match to the Entity SO from the successively generated 
Match Candidate SOs, a record written to yet another LU 
entitled Unable To Locate, or UTL, LU 342. Reports from 
the UTL LU are periodically generated for manual verifi- 
cation since they represent bankruptcy notices filed by an 
entity in which the Issuer is listed as a creditor but for which 
the Issuer has no record of an account with the entity. 
[0072] As can be seen in this specification, at several 
points in the preferred embodiment of the present invention, 
data extracted from bankruptcy-related notices is tested for 
"matches" to data residing in the various LUs. Similarly, 
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Entity SOs are tested for "matches" to Match Candidate 
SOs. It is important to point out that the determination of 
whether a "match" has occurred is of critical importance to 
the accuracy of the method of the present invention and 
therefore particular care must be exercised in the design of 
the logic for various matching mechanisms which can be 
utilized and which are well known to those skilled in the 
relevant art. 

[0073] The preferred embodiment of the present invention 
utilizes a two-tier matching logic. Generally speaking, the 
present method compares two database "records", each 
containing multiple "fields" of data. The first tier of the 
matching logic, utilizes a set of rules referred to as "Match- 
ing Rules". Matching Rules function at the field-comparison 
level. Matching Rules define what level of similarity 
between corresponding fields of the two records being 
compared is considered to be a match. For example, when 
comparing an Entity SO with a Match Candidate SO, each 
of the two SOs may have a field which corresponds to a 
person's name. JTie Matching Rules determine how closely 
the names in each SO must be to each other before the two 
fields are considered a match. 

[0074] Matching Rules may consist of one or more tests 
applied to the two data fields in question as well as a 
predetermined minimum threshold of similarity beyond 
which a match is presumed. As an illustration, one of the 
data fields may contain the string "John Q. Public" while the 
second filed may contain the string "John Q Public". If a 
"charactcr-for-charactcr" test is applied to the two fields, it 
will reveal that the two fields are not a 100% identical 
because the first field contains a period after the middle 
initial while the second doesn't. However, it is obvious to 
the human eye that the two fields should be considered a 
match. Ia order to accomplish this, a similarity threshold 
may be utilized to, for instance, dictate that a mach of 80% 
in a "charactcr-for-charactcr" test should be deemed a 
match. 

[0075] In order to increase the accuracy of Matching rules, 
the preferred embodiment of the present invention generally 
applies a number of tests, in succession, to the candidate 
fields in order to determine whether a match exists. In 
addition to a characler-for-character lest, the Matching rules 
could utilize, for example: (a) "character count" tests which 
account for transposed characters (i.e., "John" vs. "Jhon"); 
or (b) "slide tests" which account for erroneously repeated 
characters (i.e. "Smith" v. "Smiith"). Each type of test may 
have its own threshold and the results of tiie multiple tests 
may be combined into an average score to increase the 
confidence level of the result. 

[0076] Matching Rules, in general, are encoded into the 
scripting objects which perform the data comparisons as 
system wide norms which apply regardless of the type of 
record being compared. However, different Matching Rules 
may be applied to different types of data. For example, 
alphanumeric, numeric and date type fields may each have 
their own set of Matching Rules. 

[0077] The second tier of the matching logic, utilizes a set 
of rules referred to as "Comparison Rules". Comparison 
Rules operate at the record-comparison level. That is, after 
Matching Rules have been applied to compare all of the 
fields in the two records being compared, the Comparison 
Rules determine what level of similarity overall in the fields 
is sufficient to establish a match between the records. 



[0078] For example , the Comparison Rules for a p articular 
Issuer may dictate that in order to deem two records 
matched, they must have at least one field match exactly and 
two fields must match partially. For instance, a Comparison 
Rule may require that in order for an Entity SO to be deemed 
matched to a Matched Candidate SO, the two SOs must have 
an exact match in the Social Security Number filed and at 
least partial matches in the Address and Name fields. 
[0079] Comparison Rules are generally determined in 
conjunction with consultations made with the different Issu- 
ers whose credit card databases are revised using the present 
methods. A particular Issuer may follow a more conservative 
approach to matching and may wish to only consider 
matches to occur at higher threshold levels (i.e., in the 
extreme case, only deem that a match has occurred between 
records when all fields match exactly). Another Issuer may 
wish to follow a more relaxed matching standard and only 
require partial matches to establish a match between two 
records. 

[0080] In order to allow flexibility between Comparison 
Rules for different Issuers, the preferred embodiment of the 
present invention stores Comparison Rules inside the Rules 
LU 250 applicable to each Issuer. 

[0081] Accordingly, it will be understood that the pre- 
ferred embodiment of the present invention has been dis- 
closed by way of example and that other modifications and 
alterations may occur to those skilled in the art without 
departing from the scope and spirit of the appended claims. 

What is claimed is: 

1. A computer-implemented method for automatic remote 
coding of a debtor credit database with bankruptcy filing 
information comprising: 

a. al a local data processing location, the step of collecting 
bankruptcy filing reports from courts located within the 
various jurisdictions for which the method provides 
coverage; 

b. at said local data processing location, the step of 
extracting unique debtor identifying data from said 
bankruptcy filing reports; 

c. at said local data processing location, the step of 
generating a database query designed to identify data- 
base records which match said unique debtor identify- 
ing data; 

d. the step of establishing an electronic connection 
between said local data processing location and a 
remote credit database storage location, said electronic 
connection being suitable for two-way transmission of 
data between said local data processing location and 
said remote credit database storage location; 

e. the step of executing, from said local data processing 
location, said database query against a debtor credit 
database housed at said remote credit database storage 
location and identifying debtor records matching said 
database query; and 

f. the step of, coding said matching records at said debtor 
credit database with bankruptcy filing information. 




n 

| United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark Office 
Address: COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria, Virginia 223 13-1450 



APPLICATION NO. 



FIRST NAMED INVENTOR 



10/729,517 



12/05/2003 



12532 7590 02/12/2007 

PROSKAUER ROSE LLP 

ONE INTERNATIONAL PLACE 14TH FL 

BOSTON, MA 02110 



Brian D. Oxman 



| ATTORNEY DOCKET NO. | CONFIRMATION NO. [ 



r 



COLAN, GIOVANNA B 



PAPER NUMBER 



SHORTENED STATUTORY PERIOD OF RESPONSE 



DELIVERY MODE 



Please find below and/or attached an Office communication concerning this application or proceeding. 

If NO period for reply is specified above, the maximum statutory period will apply and will expire 6 MONTHS 
from the mailing date of this communication. 



ECEflVE 
FEB 16 2007 



PTOL-90A (Rev. 10/06) 



E. 





Application No. 


Applicants) 




Office Action Summary 


10/729,517 


OXMANETAL. 




Examiner 

Giovanna Colan 


Art Unit 
2162 





- The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE I MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .1 36(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply Is specified above, the maximum statutory period wM apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 1 33). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704{b). 

Status 

1 )M Responsive to communication(s) filed on 10 October 2006 . 
2aM This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11 , 453 O.G. 213. 

Disposition of Claims 

4) E3 Claim(s) U31 is/are pending in the application. 

4a) Of the above claim(s) 4 and 25 is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) M Claim(s) 1-3. 5-24. 26-31 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D ' Ciaim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) Q The specification is objected to by the Examiner. 

10)D The drawing(s.) filed on is/are: a)Q accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 

Replacement drawing sheet(s) including the correction is required if the drawing(s) Is objected to. See 37 CFR 1 .121(d). 
1 1 )□ The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

t2)D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)DAII b)D Some *c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

2. D Certified copies of the priority documents have been received in Application No. . 

3. Q Copies of the certified copies of the priority documents have been received In this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attachments) 

1) [X] Notice of References Cited (PTO-892) 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) 

3) □ Information Disclosure Statements) (PTO/SB/08) 

Paper No(s)/Mail Date . 

J.S.PatentandTr.demarfcOffice ' 

PTOL-326 (Rev. 08-06) Office , 



4) []] Interview Summary (PTO-41 3) 

Paper No(s)/Mall Date. . 

5) □ Notice of Informal Patent Application 

6) □ Other . 



< Summary Part of Paper No./Mall Date 20061213 



Application/Control Number: 1 0/729,51 7 Page 2 

Art Unit: 2162 

DETAILED ACTION 

1 . This action is issued in response to the Amendment filed on 1 0/1 0/2006. 

2. Claims 1 - 3, 5, 9 - 1 1 , 1 3 - 24, and 26 were amended. Claims 4, and 25 were 
canceled. Claims 27 - 31 were added. 

3. This action is made Final. 

4. Claims 1 - 3, 5 - 24, 26 - 31 are pending in this application. 

5. Applicant's arguments with respect to amended claims 1 - 3, 5, 9 - 1 1 , 13 - 24, 
and 26 have been considered but are moot in view of the new ground(s) of rejection. 



Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

7. This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
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consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 

8. Claim 1 - 3, 5 - 24, 26, and 28 - 31 are rejected under 35 U.S.C. 1 03(a) as 
being unpatentable over Broadbent et al. (Broadbent hereinafter) (US Patent App. 
Pub. 2001/0047326 A1 , published: November 29, 2001 ), in view of Fay et al. (Fay 
hereinafter) (US Patent App. Pub. 2002/0188540 A1, filed: June 8, 2001), and 
further in view Esposito (US Patent App. Pub. No. 2001/0051906 A1, filed May 1, 
2001). 



Regarding Claim 1, Broadbent discloses a computerized system for producing a 
domestic relations order comprising: 

a receiver for receiving information (Figure 4A, item 401, Page 9, [0123], lines 3 
- 8, Broadbent 1 ). However, Broadbent does not expressly disclose a domestic relations 
order. On the other hand, Fay discloses a receiver for receiving information relating to a 
domestic relations order (Page 2 and 8, [0015] and [0077], lines 1 - 6 and 1 - 8; 
respectively, Fay). It would have been obvious to one of ordinary skill in the art at the 
time the invention was made to Incorporate the Fay's teachings to the system of 
Broadbent. Skilled artisan would have been motivated to do so, as suggested by Fay 
(Page 2, [0012] and [0014], lines 1 - 3 and 3 - 5; respectively, Fay), to provide a user 
with a plurality of periodic retirement income payments; and to provide a defined 
retirement benefit which will guarantee an individual a minimum defined income level 
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upon individual's retirement. In addition, both of the references (Broadbent and Fay) 
teach features that are directed to analogous art and they are directed to the same field 
of endeavor of database management system, such as, authorization, results creation 
based on received information, and rules module. This relation between both of the 
references highly suggests an expectation of success. 

The combination of Broadbent in view of Fay furthermore discloses that: 

said information comprising an alternate payee (Figure 22, "Married to (which co- 
borrower)", Broadbent). 

However, the combination of Broadbent in view of Fay is silent with respect to 
court information. On the other hand, Esposito discloses a system similar to the 
combination of Broadbent in view of Fay's including: court information (Page 1, [0008], 
lines 5-7 and 21-29; Esposito). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the Esposito's teachings to the system the 
combination of Broadbent in view of Fay. Skilled artisan would have been motivated to 
do so, as suggested by Esposito (Page 1 , [0008], lines 14 - 19 and 23 - 25, Esposito), 
to offer a simplified compliance with federal and state rules (through an artificial 
intelligence that can identify a particular event that has occurred with respect to a 
particular employee benefit plan, and a particular employee who must receive a 
particular document and in what manner and when); and to avoid potential penalties 
assessed by a federal court or government agency for non-compliance. In addition, the 



1 Wherein examiner interprets information, such as, input borrower, property and originator date as the 
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applied references (Broadbent, Fay, and Esposito) teach features that are directed to 
analogous art and they are directed to the same field of endeavor, such as, databases 
management systems, compliance rules for documents, and employee benefit plans. 
This close relation between the applied references highly suggests an expectation of . 
success. 

Furthermore, the combination of Broadbent in view of Fay and futher in view of 
Esposito discloses: 

a rules engine in communication with the receiver for selecting sample text 
passages (Page 9, [0120], lines 10-17, Broadbent; and Page 6, [0068], lines 14-25, 
Esposito); and 

a document assembler for automatically incorporating a first subset of the sample 
text passage {Page 9, [0120], lines 10-17, Broadbent; and Page 6, [0068], lines 14 - 
25, Esposito) and a second subset of the received information comprising the alternate 
payee (Figure 22, "Married to (which co-borrower)", Broadbent) and the court 
information into a court-compliant domestic relations order for submission to a court 
(Figure 18, "loan programs that fit the criteria you entered on the previous pages", Page 
10, [0125], lines 5-9, Broadbent 2 ; Page 2 and 8, [0015] and [0077], lines 1 - 6 and 1 - 
8; respectively, Fay; and Page 1, [0008], lines 8-13, Esposito). 

Regarding Claim 2, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein a subset of the received information 



information relating to a domestic relation order claimed. 
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comprises information associated with a participant in an employee benefit plan (Page 
7, [0096], lines 7-9, employment agreement, Broadbent; and Page 1 , [0008], lines 8 - 
13, Esposito). 

Regarding Claim 3, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein, received information comprises 
information associated with a legal representative of the participant (Figure 30, 
"Welcome, Joe Realtor", Page 7, [0097], lines 1 - 7, Broadbent). 

Regarding Claim 5, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein, the received information comprises 
information associated with a legal representative of the alternate payee (Figure 22 and 
30, Page 7, [0097], lines 1 - 7, Broadbent). 

Regarding Claim 6, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system further including a data storage device for storing 
rules relating to a domestic relations order (Page 4 and 16, [0051] and [0202], lines 1 - 
6 and 1 - 3; respectively, Broadbent; and Page 2 and 8, [0015] and [0077], lines 1 - 6 
and 1 - 8; respectively, Fay). 



2 Wherein the step of displaying specific loan programs (as in Figure 18, Broadbent) corresponds to the 
step of selecting a subset of the sample text passages claimed. 
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Regarding Claim 7, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein the data storage device further stores 
sample text passages (Figure 5 and 22, item 543 and "save" in Figure 22, Page 20, 
[0219], lines 17-22; respectively, Broadbent). 

Regarding Claim 8, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein the sample text passages relate to a 
domestic relations order (Figure 5 and 22, item 543 and "save" in Figure 22, Page 20, 
[0219], lines 17-22; respectively, Broadbent; and Page 2 and 8, [0015] and [0077], 
lines 1 - 6 and 1 - 8; respectively, Fay). 

Regarding Claim 9, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein the rules engine further selects a first 
subset of the sample text passages based, at least in part, on the stored rules (Page 9, 
[0120], lines 10-17, Broadbent; and Page 6, [0068], lines 14 - 25, Esposito). 

Regarding Claim 10, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein the rules engine further selects a first 
subset of the sample text passages based, at least in part, on the received information 



E. 
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(Figure 18, "loan programs that fit the criteria you entered on the previous pages", Page 
10, [0125], lines 5-9, Broadbent 3 ; and Page 6, [0068], lines 14-25, Esposito). 

Regarding Claim 1 1 , the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein the document assembler receives 
additional information from the data storage device, the additional information having 
been previously included in a domestic relations order (Page 13, [0177], lines 8-13, 
the previous 'override' application, Broadbent; and Page 2 and 8, [0015] and [0077], 
lines 1 - 6 and 1 - 8; respectively, Fay). 

Regarding Claim 1 2, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system further comprising an administrative module for 
maintaining the rules engine (Page 4, [0051], lines 1 - 4, Broadbent). 

Regarding Claim 13, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a computerized method for producing a domestic relations 
order, comprising: 

providing a plurality of sample text passages relating to domestic relations orders 
(Figure 23, "1234 any Street", Broadbent 4 ; and Page 2 and 8, [0015] and [0077], lines 1 
- 6 and 1-8; respectively, Fay), the sample text passages including embedded 

3 Wherein the step of displaying specific loan programs (as in Figure 18, Broadbent) corresponds to the 
step of selecting a subset of the sample text passages claimed. 
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parameters (Figure 23, Current Street Address, Broadbent 5 ) comprising an alternate 
payee Figure 22, "Married to (which co-borrower)", Broadbent) and court information 
(Page 1 , [0008], lines 5 - 7 and 21 - 29; Esposito); 

requesting information for inclusion into a domestic relations order (Figure 24, 
Broadbent; and Page 2 and 8, [0015] and [0077], lines 1 - 6 and 1 - 8; respectively, 
Fay), the requested information including values for one or more of the embedded 
parameters (Figure 24, item showing value " $15000", Page 21, [0238], lines 1 - 3, 
Broadbent 6 ); 

receiving the requested information (Figure 4A, item 401 , Page 9, [0123], lines 3 
- 8, Broadbent 7 ); and 

automatically assembling court-compliant domestic relations order (Page 2 and 
8, [0015] and [0077], lines 1 - 6 and 1 - 8; respectively, Fay) for submission to a court 
using a first subset of the sample text passages (Page 9, [0120], lines 10-17, 
Broadbent; and Page 6, [0068], lines 14-25, Esposito) and a second subset of the 
requested information (Figure 4D, items 482 and 483, Page 10, [0125] and [0126], lines 
14 - 17 and 18 - 21 ; respectively, Broadbent 8 ; and Page 1 , [0008], lines 8-13, 
Esposito). 



Wherein "1234 any Street" corresponds to the sample text passage claimed. In addition, the text that 
would be entered in the text box (Figure 29, Broadbent) corresponds to another sample text passage 
claimed. 

* Wherein "Current Street Address" corresponds to the embedded parameter claimed. 
Wherein the value "$1 500" corresponds to the value claimed; and "Estimated Property Value" 
corresponds to the parameter claimed. 

7 Wherein examiner interprets information, such as, input borrower, property and originator date as the 
information relating to a domestic relation order claimed. 
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Regarding Claim 14, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising receiving the requested 
information over an electronic communications network (Figure 1 , item 100, typical 
internet network configuration, Page 8, [0116], lines 1 - 7, Broadbent). 

Regarding Claim 15, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method wherein the electronic communications network is 
one of a local area network, a wide area network, a telephone network, an intranet, or 
the Internet, or any other combination thereof (Figure 1 , item 100, typical internet 
network configuration, Page 8, [0116], lines 1 - 7, Broadbent). 

Regarding Claim 16, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising receiving the requested 
information through an online questionnaire (Figure, 15, Page 5, [0061], lines 5-10, 
Broadbent). 

Regarding Claim 17, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising receiving at least a subset of the 
requested information from a previously completed domestic relations order (Page 13, 
[0177], lines 8-13, the previous 'override' application, Broadbent; and Page 2 and 8, 
[0015] and [0077], lines 1 - 6 and 1 - 8; respectively, Fay). 



8 Wherein the file, specifically, the worker compensation and loan completion report correspond to the 
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Regarding Claim 18, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising receiving at least a subset of the 
requested information associated with a participant in an employee benefit plan (Page 
7, [0096], lines 7-9, employment agreement, Broadbent; and Page 1 , [0008], lines 8 - 
13, Esposito). 

Regarding Claim 19, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method wherein the employee benefit plan comprises a 
defined contribution plan and a defined benefit plan, or both (Page 7, [0096], lines 7-9, 
employment agreement, Broadbent; and Page 1, [0008], lines 8-13, Esposito). 

Regarding Claim 20, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising receiving a subset of the 
requested information associated with a legal representative of a participant in an 
employee benefit plan (Figure 30, "Welcome, Joe Realtor", Page 7, [0097], lines 1 - 7, 
Broadbent). 

Regarding Claim 21 , the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising receiving a subset of the 



assembled domestic relations order claimed. 
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requested information from an alternate payee of an employee benefit plan (Figure 22, 
"Married to (which co-borrower)", Broadbent). 

Regarding Claim 22, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising receiving at least a subset of the 
requested information associated with a legal representative of the alternate payee of 
an employee benefit plan (Figure 22 and 30, Page 7, [0097], lines 1 - 7, Broadbent). 

Regarding Claim 23, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising providing a set of rules relating 
to the generating a domestic relations order (Page 4 and 16, [0051] and [0202], lines 1 
-6 and 1 - 3; respectively, Broadbent; and Page 2 and 8, [0015] and [0077], lines 1 - 6 
and 1 - 8; respectively, Fay). 

Regarding Claim 24, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method wherein automatically assembly the court- 
compliant domestic order comprises determining the subset of the sample text 
passages based, at least in part, on the rules (Page 9, [0120], lines 10-17, Brpadbent; 
Page 2 and 8, [0015] and [0077], lines 1 - 6 and 1 - 8; respectively, Fay; and Page 1 , 
[0008], lines 8-13, Esposito). 



E. 
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Regarding Claim 26, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a computerized system for producing a domestic relations 
order, comprising: 

means for storing sample text passages for inclusion into a domestic relations 
order, the sample text passages including embedded parameters (Figure 5 and 22, item 
543 and "save" in Figure 22, Page 20, [0219], lines 17 - 22; respectively, Broadbent 9 ; 
and Page 2 and 8, [0015] and [0077], lines 1 - 6 and 1 - 8; respectively, Fay) 
comprising an alternate payee Figure 22, "Married to (which co-borrower)", Broadbent) 
and court information (Page 1 , [0008], lines 5 - 7 and 21 - 29; Esposito); 

means for receiving information about a first domestic relations order (Figure 24, 
Broadbent; and Page 2 and 8, [0015] and [0077], lines 1 - 6 and 1 - 8; respectively, 
Fay), the information providing values for one or more of the embedded parameters 
(Figure 24, item showing value " $15000", Page 21, [0238], lines 1 - 3, Broadbent 10 ); 
and 

means for automatically assembling ccjri -compliant domestic relations order 
(Page 2 and 8, [0015] and [0077], lines 1 - 6 and 1 - 8; respectively, Fay) for 
submission to a court using a first subset of the sample text passages (Page 9, [0120], 
lines 10-17, Broadbent; and Page 6, [0068], lines 14-25, Esposito) and a second 
subset of the received information (Figure 4D, items 482 and 483, Page 10, [0125] and 



^Wherein "First Name", "Last Name", etc correspond to the embedded parameters claimed 

Wherein the value "$1500" corresponds to the value claimed; and "Estimated Property Value" 
corresponds to the parameter claimed. 



E. 
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[0126], lines 14-17 and 18-21; respectively, Broadbent 11 ; and Page 1, [0008], lines 8 
- 13, Esposito). 



Regarding Claim 28, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method further comprising determining one or more 
questions for the online questionnaire based on a rules engine and a subset of the 
requested information (Page 5, [0061], lines 5-10, Broadbent). 

Regarding Claim 29, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method wherein assembling comprises using a document 
template (Page 7, [0073, lines 12-20, Esposito). 

Regarding Claim 30, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a method wherein automatically assembling the court- 
compliant domestic relations order comprises using a subset of the requested 
information as input for one or more parameter fields of the document template (Page 9, 
[0120], lines 10-17, Broadbent; Page 2 and 8, [0015] and [0077], lines 1 - 6 and 1 - 8; 
respectively, Fay; and Page 6, [0068], lines 14-25, Esposito). 

Regarding Claim 31 , the combination of Broadbent in view of Fay and further in 
view of Esposito discloses a system wherein the court-compliant domestic relations 

11 Wherein the file, specifically, the worker compensation and loan completion report correspond to the 
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order is assembled according to one or more predefined document formats (Page 26, 
[0280], lines 14-26, Broadbent; and Page 3, [0037], lines 1 - 8, Esposito). 



9. Claim 27 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Broadbent et al. (Broadbent hereinafter) (US Patent App. Pub. 2001/0047326 A1, 
published: November 29, 2001), in view of Fay et al. (Fay hereinafter) (US Patent 
App. Pub. 2002/0188540 A1, filed: June 8, 2001), in view Esposito (US Patent App. 
Pub. No. 2001/0051906 A1, filed May 1, 2001), and further in view of Cohen et al. 
(Cohen hereinafter) (US Patent App. Pub. No. 2004/0064404 A1, filed: October 1, 
2002). 

Regarding Claim 27, the combination of Broadbent in view of Fay and further in 
view of Esposito discloses all the limitations as discussed above including court 
information. However, the combination of Broadbent in view of Fay and further in view 
of Esposito is silent with respect to a case number. On the other hand, Cohen discloses 
court information and a case number (Page 4, [0042], lines 1 - 8, Cohen). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the Cohen's teachings to the system of the 
combination of Broadbent in view of Fay and further in view of Esposito. Skilled artisan 
would have been motivated to do so, as suggested by Cohen (Page 4, [0042], lines 4 - 



assembled domestic relations order claimed. 
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8, Cohen), to provide specific data about a case. In addition, the applied references 
(Broadbent, Fay, Esposito* and Cohen) teach features that are directed to analogous art 
and they are directed to the same field of endeavor, such as, databases management 
systems, court information. This close relation between the applied references highly 
suggests an expectation of success. 
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Conclusion 

1 . The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 



2. THIS ACTION IS MADE FINAL Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 



E. 
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Prior Art Made Of Record 

1 . Broadbent et al. (US Patent App. Pub. 2001/0047326 A1 , published: November 
29, 2001 ) discloses an interface system for mortgage loan originator compliance 
engine. 

2. Hueler (US Patent App. Pub. No. 2003/0004844, filed: April 25, 2001 ) discloses 
an independent annuity placement system and method. 

3. Fay et al. (US 2002/01 88540 A1 ) discloses a method and system for portable 
retirement investment. 

4. Stiff et al. (US 2002/01 94098 A1 ) discloses a system and method for 
guaranteeing minimum periodic retirement income payments using an adjustment 
account. 

5. Florance et al. (US 2003/0078897 A1 ) discloses a system and method for 
collection, distribution, and use of information in connection with commercial real state. 

6. Esposito (US Patent App. Pub. No. 2001/0051 906 A1 , filed May 1 , 2001 ). 

7. Cohen et al. (US Patent App. Pub. No. 2004/0064404 A1 , filed: October 1 , 2002). 



E. 
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Points Of Contact 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Giovanna Colan whose telephone number is (571) 272- 
2752. The examiner can normally be reached on 8:30 am - 5:00 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Breene can be reached on (571) 272-4107. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Giovanna Colan 
Examiner 
Art Unit 2162 



December 13, 2006 
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